On Sun, Nov 18, 2012 at 7:22 AM, Edward Diener <eldiener@tropicsoft.com>wrote:
On 11/16/2012 12:32 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Nov 15, 2012 at 7:04 PM, Edward Diener <eldiener@tropicsoft.com>* *wrote:
I have found something like this to be helpful, when working with
multiple compilers:
#include <boost/config.hpp> #if defined(BOOST_NO_NULLPTR) #define BOOST_XXX_NULLPTR 0 #else #define BOOST_XXX_NULLPTR nullptr #endif
where XXX is some local name for my own use. And then use BOOST_XXX_NULLPTR in places where a null pointer is needed.
Would this be a candidate for a BOOST_NULLPTR macro in the config library instead ?
Might it be better to just offer a (albeit imperfect) nullptr emulation if not supplied by the compiler? For example, [1].
- Jeff
I agree that you are right.
If the nullptr emulation has less problems than using 0 it would seem worthwhile. That appears to be easily the case. Both are of course imperfect but it appears that a nullptr emulation is far less imperfect. The question then is who is going to do it and support it, given that it will most probably be obsolete in the near future as more compilers implement features of C++11. Unless someone steps up to do it ( and I am not that person due to, for one, already being behind in getting TTI into Boost ) it will not be done and then using 0 is at least a second best solution.
In my own current use of nullptr in cross-compiler code for Boost using 0 is adequate for my means in the few instances where I am using nullptr. So my suggestion in my OP is adequate for me right now but may well not be adequate for others or for future usage on compilers which do not support nullptr.
I'll post something this week and if it's ultimately decided to be included in, e.g., boost/utility, I don't have a problem supporting it. - Jeff