Andrey Semashev wrote:
On Thu, Dec 6, 2012 at 7:42 AM, Jeffrey Lee Hellrung, Jr. wrote:
Or, as Nathan suggested, drop trying to emulate the literal nullptr
keyword
and just define and use boost::nullptr_. That's probably the best option. Slightly uglier, but no macros and no name collisions.
Nathan's code sample has an error, it always uses boost::detail::nullptr_t to define nullptr_. After correcting this I'm not sure that the following:
namespace boost {
typedef std::nullptr_t nullptr_t; const nullptr_t nullptr_ = {};
}
is valid and supposed to work. If I'm not mistaken, we know almost nothing about std::nullptr_t. In particular, we don't know if it's default constructible and if it is, will it be equivalent to nullptr.
The particular initialization of the previous may not be legal, but from the standard it appears that contructing std::nullptr_t should work. This post [1] seems to agree with my reading (and it has references).
Also, boost::nullptr is supposed to help writing C++11-style code even for C++03 compilers. With a different keyword that doesn't hold anymore, a migration path is needed. I'm not sure it's worth the effort in this case.
True. It would be nice if there was *something* which was implicitly convertible to a null shared_ptr<T> (regardless of T) -- that's the biggest place I miss nullptr in my current code. Construction from boost::none is a really nice usability feature of boost::optional. Thanks, Nate [1] < http://stackoverflow.com/questions/9953068/is-nullptr-t-a-default-constructi...