Jason Hise wrote:
Martin Wille wrote:
Jason Hise wrote: [...] I also object to this idea in general. It doesn't buy us much, it breaks existing code, it may cause ODR violations, and it also violates the C++ Standard.
What existing code will it break? I would imagine it would only break code that deserves to be broken in the first place (like int i = NULL).
Eric already provided an example for code breaking with your definition of NULL. There's nothing wrong with int i = NULL. It's certainly not good style, but that doesn't make it deserve to be broken.
Also, how would this cause ODR violations? I was under the impression that the one definition rule required all definitions in different translation units to be identical, not that it required that a definition only be provided in one translation unit.
a.hpp: #include "boost/null.hpp" b.hpp: #include <cstddef> c.hpp: /* e.g. template code that uses NULL */ x.cpp: #include "b.hpp" #include "a.hpp" #include "c.hpp" /* use stuff from c.hpp */ y.hpp: #include "b.hpp" #include "c.hpp" /* use stuff from c.hpp */ x and y will instantiate different code due to the different #include order. And even if
somehow more than one instance of null ended up being used, how would this actually end up causing a problem?
It's undefined behaviour. Would your problem with this
code vanish if I removed the NULL definition on the last two lines?
Yes.
Would it reappear if I moved the null class into the global namespace (essentially making lowercase null a keyword)?
Adding stuff to the global namespace bears its own set of problems. You would definitely break a lot of code that defines its own null constants. It's certainly less of a problem than re#defining NULL would be. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com