<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Accessing static members via an instance</title>
	<link>https://codesynthesis.com/~boris/blog//2012/02/21/access-static-members-via-instance/</link>
	<description>Boris Kolpackov's blog about software</description>
	<pubDate>Fri, 10 Apr 2026 21:59:05 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.2</generator>

	<item>
		<title>By: Boris Kolpackov</title>
		<link>https://codesynthesis.com/~boris/blog//2012/02/21/access-static-members-via-instance/#comment-1867</link>
		<author>Boris Kolpackov</author>
		<pubDate>Tue, 28 Feb 2012 11:24:56 +0000</pubDate>
		<guid>https://codesynthesis.com/~boris/blog//2012/02/21/access-static-members-via-instance/#comment-1867</guid>
		<description>Good question. It seems the answer depends on how you interpret the standard. I agree it is probably best to avoid accessing a non-static member via a NULL pointer. In case of a static member, however, I don't see any logical reason why it cannot be done safely even if one can interpret the standard in such a way that it calls for undefined behavior. From a practical point of view, a compiler implementer will have to intentionally add extra code to cause any harm in this situation, since in the generated code x.foo() and x::foo() will result in equivalent instructions (or, in other words, x.foo() can be reduced to x::foo() at compile time).</description>
		<content:encoded><![CDATA[<p>Good question. It seems the answer depends on how you interpret the standard. I agree it is probably best to avoid accessing a non-static member via a NULL pointer. In case of a static member, however, I don&#8217;t see any logical reason why it cannot be done safely even if one can interpret the standard in such a way that it calls for undefined behavior. From a practical point of view, a compiler implementer will have to intentionally add extra code to cause any harm in this situation, since in the generated code x.foo() and x::foo() will result in equivalent instructions (or, in other words, x.foo() can be reduced to x::foo() at compile time).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon Dice</title>
		<link>https://codesynthesis.com/~boris/blog//2012/02/21/access-static-members-via-instance/#comment-1866</link>
		<author>Simon Dice</author>
		<pubDate>Mon, 27 Feb 2012 22:48:34 +0000</pubDate>
		<guid>https://codesynthesis.com/~boris/blog//2012/02/21/access-static-members-via-instance/#comment-1866</guid>
		<description>are you sure that this is not an undefined behavior? Look at this discussion for example: http://stackoverflow.com/questions/2474018/when-does-invoking-a-member-function-on-a-null-instance-result-in-undefined-beha</description>
		<content:encoded><![CDATA[<p>are you sure that this is not an undefined behavior? Look at this discussion for example: <a href="http://stackoverflow.com/questions/2474018/when-does-invoking-a-member-function-on-a-null-instance-result-in-undefined-beha" rel="nofollow">http://stackoverflow.com/questions/2474018/when-does-invoking-a-member-function-on-a-null-instance-result-in-undefined-beha</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
