[config] Macro for null pointer

classic Classic list List threaded Threaded
64 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[config] Macro for null pointer

Edward Diener-3
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 ?

Edward Diener


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Jeffrey Lee Hellrung, Jr.-2
On Thu, Nov 15, 2012 at 7:04 PM, Edward Diener <[hidden email]>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

[1] http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Antony Polukhin
2012/11/16 Jeffrey Lee Hellrung, Jr. <[hidden email]>:

> On Thu, Nov 15, 2012 at 7:04 PM, Edward Diener <[hidden email]>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
>
> [1] http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr

`nullptr_t` is also required for libraries (especially for
Boost.SmartPtr). So there must be a macro for it too.

And may be we shall typedef nullptr_t as boost::none_t ?

--
Best regards,
Antony Polukhin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Matt Calabrese
On Fri, Nov 16, 2012 at 1:39 AM, Antony Polukhin <[hidden email]>wrote:

> And may be we shall typedef nullptr_t as boost::none_t ?
>

I'm not entirely sure about this, but I'm not really sure that I'm against
it either. I just wonder if there might be some weird situations where it
could cause ambiguity or other problems. For instance, could this maybe
cause a problem or questionable/unintuitive behavior with something like
optional<int*>? Perhaps that's a weird case, but without some investigation
I'm willing to bet there might be some more subtleties.

--
-Matt Calabrese

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Andrey Semashev-2
In reply to this post by Antony Polukhin
On November 16, 2012 10:39:30 AM Antony Polukhin <[hidden email]> wrote:
>
> And may be we shall typedef nullptr_t as boost::none_t ?

nullptr_t should be implicitly convertible to any pointer type, which
none_t isn't AFAIR.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Jookia
On 16/11/12 18:18, Andrey Semashev wrote:
> On November 16, 2012 10:39:30 AM Antony Polukhin <[hidden email]>
> wrote:
>>
>> And may be we shall typedef nullptr_t as boost::none_t ?
>
> nullptr_t should be implicitly convertible to any pointer type, which
> none_t isn't AFAIR.

Are there any unit tests for nullptr floating around? Compiler vendors
perhaps?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Andrzej Krzemienski
In reply to this post by Matt Calabrese
2012/11/16 Matt Calabrese <[hidden email]>

> On Fri, Nov 16, 2012 at 1:39 AM, Antony Polukhin <[hidden email]
> >wrote:
>
> > And may be we shall typedef nullptr_t as boost::none_t ?
> >
>
> I'm not entirely sure about this, but I'm not really sure that I'm against
> it either. I just wonder if there might be some weird situations where it
> could cause ambiguity or other problems. For instance, could this maybe
> cause a problem or questionable/unintuitive behavior with something like
> optional<int*>? Perhaps that's a weird case, but without some investigation
> I'm willing to bet there might be some more subtleties.


I also believe this may cause problems. See this discussion on not using
nullptr for the proposed std::optional:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3406.html#rationale.no_nullptr

Regards,
&rzej

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Vicente Botet
In reply to this post by Antony Polukhin
Antony Polukhin wrote
2012/11/16 Jeffrey Lee Hellrung, Jr. <[hidden email]>:
> On Thu, Nov 15, 2012 at 7:04 PM, Edward Diener <[hidden email]>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
>
> [1] http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr

`nullptr_t` is also required for libraries (especially for
Boost.SmartPtr). So there must be a macro for it too.

And may be we shall typedef nullptr_t as boost::none_t ?
Why a library will need a type nullptr_t while there is only a constant in C++11? Please coul you elaborate?

Vicente
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Antony Polukhin
2012/11/16 Vicente Botet <[hidden email]>:
> Why a library will need a type nullptr_t while there is only a constant in
> C++11? Please coul you elaborate?

According to draft of C++11 (I have no final version):

Pointer literals [lex.nullptr]
pointer-literal:nullptr
The pointer literal is the keyword `nullptr`. It is a prvalue of type
`std::nullptr_t`. [ Note: `std::nullptr_t`
is a distinct type that is neither a pointer type nor a pointer to
member type; rather, a prvalue of this type is
a null pointer constant and can be converted to a null pointer value
or null member pointer value.

--
Best regards,
Antony Polukhin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Vicente Botet
In reply to this post by Jeffrey Lee Hellrung, Jr.-2
Jeffrey Lee Hellrung, Jr.-2 wrote
On Thu, Nov 15, 2012 at 7:04 PM, Edward Diener <[hidden email]>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 ?
+1.

Might it be better to just offer a (albeit imperfect) nullptr emulation if
not supplied by the compiler? For example, [1].

[1] http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr
There are two levels that can be addressed by different approaches:

* write portable code that uses C++11 nullptr when available and 0 otherwise.
* write portable code that uses C++11 nullptr when available and something safer than 0 or NULL is used to represent a null pointer otherwise.

The PO proposal corresponds to the first level, whilc IMO is already interesting.
The more elaborated proposal corresponds to the second need.

I will be for a direct inclusion of the BOOST_NULLPTR macro as part of the Boost.Config helpers, and why not accept a specific nullptr implementation if someone is ready to maintain it.

Best,
Vicente
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Vicente Botet
In reply to this post by Antony Polukhin
Le 16/11/12 13:55, Antony Polukhin a écrit :

> 2012/11/16 Vicente Botet <[hidden email]>:
>> Why a library will need a type nullptr_t while there is only a constant in
>> C++11? Please coul you elaborate?
> According to draft of C++11 (I have no final version):
>
> Pointer literals [lex.nullptr]
> pointer-literal:nullptr
> The pointer literal is the keyword `nullptr`. It is a prvalue of type
> `std::nullptr_t`. [ Note: `std::nullptr_t`
> is a distinct type that is neither a pointer type nor a pointer to
> member type; rather, a prvalue of this type is
> a null pointer constant and can be converted to a null pointer value
> or null member pointer value.
>
>
Oh, I see it now.

Thanks,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Edward Diener-3
In reply to this post by Jeffrey Lee Hellrung, Jr.-2
On 11/16/2012 12:32 AM, Jeffrey Lee Hellrung, Jr. wrote:

> On Thu, Nov 15, 2012 at 7:04 PM, Edward Diener <[hidden email]>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
>
> [1] http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr

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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Jeffrey Lee Hellrung, Jr.-2
On Sun, Nov 18, 2012 at 7:22 AM, Edward Diener <[hidden email]>wrote:

> On 11/16/2012 12:32 AM, Jeffrey Lee Hellrung, Jr. wrote:
>
>> On Thu, Nov 15, 2012 at 7:04 PM, Edward Diener <[hidden email]>*
>> *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
>>
>> [1] http://en.wikibooks.org/wiki/**More_C%2B%2B_Idioms/nullptr<http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr>
>>
>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Jeffrey Lee Hellrung, Jr.-2
On Sun, Nov 18, 2012 at 2:03 PM, Jeffrey Lee Hellrung, Jr. <
[hidden email]> wrote:

> On Sun, Nov 18, 2012 at 7:22 AM, Edward Diener <[hidden email]>wrote:
>
>> On 11/16/2012 12:32 AM, Jeffrey Lee Hellrung, Jr. wrote:
>>
>>> On Thu, Nov 15, 2012 at 7:04 PM, Edward Diener <[hidden email]>
>>> **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
>>>
>>> [1] http://en.wikibooks.org/wiki/**More_C%2B%2B_Idioms/nullptr<http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr>
>>>
>>
>> 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.
>

First go at it:

/*** BEGIN NULLPTR DEFINITION ***/

#include <boost/config.hpp>

#ifndef BOOST_NO_NULLPTR

#include <cstddef>

namespace boost
{

typedef std::nullptr_t nullptr_t;

} // namespace boost

#else // #ifndef BOOST_NO_NULLPTR

#include <ostream>

namespace boost
{

struct nullptr_t
{
  template< class T >
  operator T * () const
  { return static_cast< T * >(0); }

  template< class T, class C >
  operator T C:: * () const
  { return static_cast< T C:: * >(0); }

#ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS

  explicit operator bool () { return false; }

#else // #ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS

private:
  struct _boost_explicit_operator_bool_struct { };
  typedef int
(_boost_explicit_operator_bool_struct::*_boost_explicit_operator_bool_result_type);
public:
  operator _boost_explicit_operator_bool_result_type () const { return 0; }

#endif // #ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS

  // Must be public in order for nullptr_t to be POD.
  void * _boost_nullptr_sizeof;

#ifndef BOOST_NO_DELETED_FUNCTIONS
  void operator & () const = delete;
#else // #ifndef BOOST_NO_DELETED_FUNCTIONS
  private: void operator & () const;
#endif // #ifndef BOOST_NO_DELETED_FUNCTIONS
};

boost::nullptr_t const nullptr = { 0 };

inline bool operator==(boost::nullptr_t, boost::nullptr_t) { return true; }
inline bool operator!=(boost::nullptr_t, boost::nullptr_t) { return false; }

inline std::ostream &
operator<<(std::ostream & o, boost::nullptr_t)
{ return o << static_cast< void * >(0); }

} // namespace boost

using boost::nullptr;

#endif // #ifndef BOOST_NO_NULLPTR

/*** END NULLPTR DEFINITION ***/

#include <cassert>

#include <boost/implicit_cast.hpp>
#include <boost/static_assert.hpp>

struct X { };

int main(int argc, char * argv[])
{
  BOOST_STATIC_ASSERT( sizeof( nullptr ) == sizeof( void * ) );
  assert(!static_cast< bool >(nullptr));
  assert(!nullptr);
  assert(boost::implicit_cast< void * >(nullptr) == 0);
  assert(boost::implicit_cast< int * >(nullptr) == 0);
  assert(boost::implicit_cast< int X::* >(nullptr) == 0);
  //assert(nullptr == static_cast< void * >(0));
  //assert(nullptr != &argc);
  return 0;
}

Unfortunately, the assertions that are commented out in main trigger an ICE
on MSVC9 (yeah, big surprise); it's possible I did something wrong, but in
the event that I didn't, if we can find a workaround to get such
expressions to work, that'd be great (I tried explicitly defining
operator== and operator!= out-of-line, and that didn't help).

Also, I only tested this on MSVC9 (for now).

Comments?

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Andrey Semashev-2
On Wed, Nov 28, 2012 at 3:35 AM, Jeffrey Lee Hellrung, Jr.
<[hidden email]> wrote:
>
> First go at it:
>
> /*** BEGIN NULLPTR DEFINITION ***/
>
> #include <boost/config.hpp>
>
> #ifndef BOOST_NO_NULLPTR

I believe, the actual macros for C++11 features start with
BOOST_NO_CXX11_ (e.g. BOOST_NO_CXX11_NULLPTR). The ones without CXX11
are deprecated.

> #include <cstddef>
>
> namespace boost
> {
>
> typedef std::nullptr_t nullptr_t;
>
> } // namespace boost
>
> #else // #ifndef BOOST_NO_NULLPTR
>
> #include <ostream>

<iosfwd>, please.

> namespace boost
> {
>
> struct nullptr_t
> {
>   template< class T >
>   operator T * () const
>   { return static_cast< T * >(0); }
>
>   template< class T, class C >
>   operator T C:: * () const
>   { return static_cast< T C:: * >(0); }
>
> #ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS
>
>   explicit operator bool () { return false; }
>
> #else // #ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS
>
> private:
>   struct _boost_explicit_operator_bool_struct { };
>   typedef int
> (_boost_explicit_operator_bool_struct::*_boost_explicit_operator_bool_result_type);
> public:
>   operator _boost_explicit_operator_bool_result_type () const { return 0; }
>
> #endif // #ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS
>
>   // Must be public in order for nullptr_t to be POD.
>   void * _boost_nullptr_sizeof;
>
> #ifndef BOOST_NO_DELETED_FUNCTIONS
>   void operator & () const = delete;
> #else // #ifndef BOOST_NO_DELETED_FUNCTIONS
>   private: void operator & () const;
> #endif // #ifndef BOOST_NO_DELETED_FUNCTIONS
> };
>
> boost::nullptr_t const nullptr = { 0 };
>
> inline bool operator==(boost::nullptr_t, boost::nullptr_t) { return true; }
> inline bool operator!=(boost::nullptr_t, boost::nullptr_t) { return false; }
>
> inline std::ostream &
> operator<<(std::ostream & o, boost::nullptr_t)
> { return o << static_cast< void * >(0); }

I think, this is better:

template< typename CharT, typename TraitsT >
inline std::basic_ostream< CharT, TraitsT >& operator<<
(std::basic_ostream< CharT, TraitsT >& strm, boost::nullptr_t)
{
  o << static_cast< void * >(0);
  return o;
}

It will also not require basic_ostream to be defined.

> } // namespace boost
>
> using boost::nullptr;
>
> #endif // #ifndef BOOST_NO_NULLPTR
>
> /*** END NULLPTR DEFINITION ***/
>
> #include <cassert>
>
> #include <boost/implicit_cast.hpp>
> #include <boost/static_assert.hpp>
>
> struct X { };
>
> int main(int argc, char * argv[])
> {
>   BOOST_STATIC_ASSERT( sizeof( nullptr ) == sizeof( void * ) );
>   assert(!static_cast< bool >(nullptr));
>   assert(!nullptr);
>   assert(boost::implicit_cast< void * >(nullptr) == 0);
>   assert(boost::implicit_cast< int * >(nullptr) == 0);
>   assert(boost::implicit_cast< int X::* >(nullptr) == 0);
>   //assert(nullptr == static_cast< void * >(0));
>   //assert(nullptr != &argc);
>   return 0;
> }
>
> Unfortunately, the assertions that are commented out in main trigger an ICE
> on MSVC9 (yeah, big surprise); it's possible I did something wrong, but in
> the event that I didn't, if we can find a workaround to get such
> expressions to work, that'd be great (I tried explicitly defining
> operator== and operator!= out-of-line, and that didn't help).

Will it help if you also define templated comparison operators with pointers?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Marshall Clow-2
On Nov 27, 2012, at 11:05 PM, Andrey Semashev <[hidden email]> wrote:

> On Wed, Nov 28, 2012 at 3:35 AM, Jeffrey Lee Hellrung, Jr.
> <[hidden email]> wrote:
>>
>> First go at it:
>>
>> /*** BEGIN NULLPTR DEFINITION ***/
>>
>> #include <boost/config.hpp>
>>
>> #ifndef BOOST_NO_NULLPTR
>
> I believe, the actual macros for C++11 features start with
> BOOST_NO_CXX11_ (e.g. BOOST_NO_CXX11_NULLPTR). The ones without CXX11
> are deprecated.

That is correct.

See http://www.boost.org/doc/libs/1_52_0/libs/config/doc/html/boost_config/boost_macro_reference.html#boost_config.boost_macro_reference.boost_deprecated_macros for a complete list of deprecated macros and their replacements.

-- Marshall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Jeffrey Lee Hellrung, Jr.-2
In reply to this post by Andrey Semashev-2
On Tue, Nov 27, 2012 at 11:05 PM, Andrey Semashev <[hidden email]
> wrote:

> On Wed, Nov 28, 2012 at 3:35 AM, Jeffrey Lee Hellrung, Jr.
> <[hidden email]> wrote:
> >
> > First go at it:
> >
> > /*** BEGIN NULLPTR DEFINITION ***/
> >
> > #include <boost/config.hpp>
> >
> > #ifndef BOOST_NO_NULLPTR
>
> I believe, the actual macros for C++11 features start with
> BOOST_NO_CXX11_ (e.g. BOOST_NO_CXX11_NULLPTR). The ones without CXX11
> are deprecated.
>

Right, I just hadn't installed 1.52.0 yet; this macro transition seemed to
be only halfway done in 1.51.0.

> #include <cstddef>
> >
> > namespace boost
> > {
> >
> > typedef std::nullptr_t nullptr_t;
> >
> > } // namespace boost
> >
> > #else // #ifndef BOOST_NO_NULLPTR
> >
> > #include <ostream>
>
> <iosfwd>, please.
>

Ah, need to overload on basic_ostream for that to work, of course.

> namespace boost
> > {
> >
> > struct nullptr_t
> > {
> >   template< class T >
> >   operator T * () const
> >   { return static_cast< T * >(0); }
> >
> >   template< class T, class C >
> >   operator T C:: * () const
> >   { return static_cast< T C:: * >(0); }
> >
> > #ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS
> >
> >   explicit operator bool () { return false; }
> >
> > #else // #ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS
> >
> > private:
> >   struct _boost_explicit_operator_bool_struct { };
> >   typedef int
> >
> (_boost_explicit_operator_bool_struct::*_boost_explicit_operator_bool_result_type);
> > public:
> >   operator _boost_explicit_operator_bool_result_type () const { return
> 0; }
>

I guess this could be simplified slightly with just

typedef (nullptr_t::*_boost_explicit_operator_bool_result_type);

>
> > #endif // #ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS
> >
> >   // Must be public in order for nullptr_t to be POD.
> >   void * _boost_nullptr_sizeof;
> >
> > #ifndef BOOST_NO_DELETED_FUNCTIONS
> >   void operator & () const = delete;
> > #else // #ifndef BOOST_NO_DELETED_FUNCTIONS
> >   private: void operator & () const;
> > #endif // #ifndef BOOST_NO_DELETED_FUNCTIONS
> > };
> >
> > boost::nullptr_t const nullptr = { 0 };
> >
> > inline bool operator==(boost::nullptr_t, boost::nullptr_t) { return
> true; }
> > inline bool operator!=(boost::nullptr_t, boost::nullptr_t) { return
> false; }
> >
> > inline std::ostream &
> > operator<<(std::ostream & o, boost::nullptr_t)
> > { return o << static_cast< void * >(0); }
>
> I think, this is better:
>
> template< typename CharT, typename TraitsT >
> inline std::basic_ostream< CharT, TraitsT >& operator<<
> (std::basic_ostream< CharT, TraitsT >& strm, boost::nullptr_t)
> {
>   o << static_cast< void * >(0);
>   return o;
> }
>
> It will also not require basic_ostream to be defined.
>

Right.


> > } // namespace boost
> >
> > using boost::nullptr;
> >
> > #endif // #ifndef BOOST_NO_NULLPTR
> >
> > /*** END NULLPTR DEFINITION ***/
> >
> > #include <cassert>
> >
> > #include <boost/implicit_cast.hpp>
> > #include <boost/static_assert.hpp>
> >
> > struct X { };
> >
> > int main(int argc, char * argv[])
> > {
> >   BOOST_STATIC_ASSERT( sizeof( nullptr ) == sizeof( void * ) );
> >   assert(!static_cast< bool >(nullptr));
> >   assert(!nullptr);
> >   assert(boost::implicit_cast< void * >(nullptr) == 0);
> >   assert(boost::implicit_cast< int * >(nullptr) == 0);
> >   assert(boost::implicit_cast< int X::* >(nullptr) == 0);
> >   //assert(nullptr == static_cast< void * >(0));
> >   //assert(nullptr != &argc);
> >   return 0;
> > }
> >
> > Unfortunately, the assertions that are commented out in main trigger an
> ICE
> > on MSVC9 (yeah, big surprise); it's possible I did something wrong, but
> in
> > the event that I didn't, if we can find a workaround to get such
> > expressions to work, that'd be great (I tried explicitly defining
> > operator== and operator!= out-of-line, and that didn't help).
>
> Will it help if you also define templated comparison operators with
> pointers?
>

You mean

template< class T >
inline bool operator==(boost::nullptr_t, T * const p) { return 0 == p; }

? Yeah, no dice.

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Jeffrey Lee Hellrung, Jr.-2
On Wed, Nov 28, 2012 at 8:33 AM, Jeffrey Lee Hellrung, Jr. <
[hidden email]> wrote:

> On Tue, Nov 27, 2012 at 11:05 PM, Andrey Semashev <
> [hidden email]> wrote:
>
>> On Wed, Nov 28, 2012 at 3:35 AM, Jeffrey Lee Hellrung, Jr.
>> <[hidden email]> wrote:
>>
> [...]

> > private:
> >   struct _boost_explicit_operator_bool_struct { };
> >   typedef int
> >
> (_boost_explicit_operator_bool_struct::*_boost_explicit_operator_bool_result_type);
> > public:
> >   operator _boost_explicit_operator_bool_result_type () const { return
> 0; }
>

I guess this could be simplified slightly with just

typedef (nullptr_t::*_boost_explicit_operator_bool_result_type);

----

And by that, I mean

typedef int (nullptr_t::*_boost_explicit_operator_bool_result_type);

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Jeffrey Lee Hellrung, Jr.-2
In reply to this post by Jeffrey Lee Hellrung, Jr.-2
On Tue, Nov 27, 2012 at 3:35 PM, Jeffrey Lee Hellrung, Jr. <
[hidden email]> wrote:
[...]

> First go at it:
>

> /*** BEGIN NULLPTR DEFINITION ***/
>
> #include <boost/config.hpp>
>
> #ifndef BOOST_NO_NULLPTR
>
> #include <cstddef>
>
> namespace boost
> {
>
> typedef std::nullptr_t nullptr_t;
>
> } // namespace boost
>
> #else // #ifndef BOOST_NO_NULLPTR
>
[...]

>
> using boost::nullptr;
>

One thing I wonder about is if this using declaration is The Right Thing To
Do. An alternative is to provide a macro to bring the nullptr identifier
into the current scope (and which does nothing in C++11).


> #endif // #ifndef BOOST_NO_NULLPTR
>
[...]

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] Macro for null pointer

Andrey Semashev-2
On Wed, Nov 28, 2012 at 8:43 PM, Jeffrey Lee Hellrung, Jr.
<[hidden email]> wrote:
>>
>> using boost::nullptr;
>>
>
> One thing I wonder about is if this using declaration is The Right Thing To
> Do. An alternative is to provide a macro to bring the nullptr identifier
> into the current scope (and which does nothing in C++11).

I don't like the macro with using declaration. I'd rather have this
using declaration in the header, with possibility to disable it by
defining a config macro:

#ifndef BOOST_NO_GLOBAL_NULLPTR
using boost::nullptr;
#endif

And I want this declaration to be enabled by default since the
language keyword is not scoped in a namespace and that's what we try
to emulate. The macro switch is only there to solve problems if they
arise.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234