What is boost's unspecified_bool_type?

Discussion in 'C++' started by dru, Apr 28, 2004.

  1. dru

    dru Guest

    Every time I think I know or understand C++ with some
    confidence, I see something that changes that.

    I was looking at the boost shared_ptr docs and code, and
    I ran across the operator unspecified_bool_type()

    In the code they have this:


    #if defined(__SUNPRO_CC) && BOOST_WORKAROUND(__SUNPRO_CC, <= 0x530)

    operator bool () const
    {
    return px != 0;
    }

    #elif defined(__MWERKS__) && BOOST_WORKAROUND(__MWERKS__,
    BOOST_TESTED_AT(0x3003))
    typedef T * (this_type::*unspecified_bool_type)() const;

    operator unspecified_bool_type() const // never throws
    {
    return px == 0? 0: &this_type::get;
    }

    #else

    typedef T * this_type::*unspecified_bool_type;

    operator unspecified_bool_type() const // never throws
    {
    return px == 0? 0: &this_type::px;
    }

    #endif

    // operator! is redundant, but some compilers need it

    bool operator! () const // never throws
    {
    return px == 0;
    }


    Here are some things to note.

    1. That SunCC implementation is very easy to understand, and is often
    used in MSVC as well.

    2. The MWERKS workaround is fairly weird. Skip it.

    3. The third section is the real code. What is the operator really of
    with that typdef that I cannot parse???

    4. I included the operator ! just for fun. That implementation appears
    to be
    straigthfowrard for all implementations. It's simplicity is probably a
    clue why the other ones are not; some asymetry in the C++ semantics.

    *Please post replies here, thx*
     
    dru, Apr 28, 2004
    #1
    1. Advertising

  2. "dru" <> wrote in message
    news:...
    > Every time I think I know or understand C++ with some
    > confidence, I see something that changes that.
    >


    I know that feeling.

    > I was looking at the boost shared_ptr docs and code, and
    > I ran across the operator unspecified_bool_type()
    >
    > In the code they have this:
    >
    >
    > #if defined(__SUNPRO_CC) && BOOST_WORKAROUND(__SUNPRO_CC, <= 0x530)
    >
    > operator bool () const
    > {
    > return px != 0;
    > }
    >
    > #elif defined(__MWERKS__) && BOOST_WORKAROUND(__MWERKS__,
    > BOOST_TESTED_AT(0x3003))
    > typedef T * (this_type::*unspecified_bool_type)() const;
    >
    > operator unspecified_bool_type() const // never throws
    > {
    > return px == 0? 0: &this_type::get;
    > }
    >
    > #else
    >
    > typedef T * this_type::*unspecified_bool_type;
    >
    > operator unspecified_bool_type() const // never throws
    > {
    > return px == 0? 0: &this_type::px;
    > }
    >
    > #endif
    >
    > // operator! is redundant, but some compilers need it
    >
    > bool operator! () const // never throws
    > {
    > return px == 0;
    > }
    >
    >
    > Here are some things to note.
    >
    > 1. That SunCC implementation is very easy to understand, and is often
    > used in MSVC as well.
    >
    > 2. The MWERKS workaround is fairly weird. Skip it.
    >
    > 3. The third section is the real code. What is the operator really of
    > with that typdef that I cannot parse???
    >
    > 4. I included the operator ! just for fun. That implementation appears
    > to be
    > straigthfowrard for all implementations. It's simplicity is probably a
    > clue why the other ones are not; some asymetry in the C++ semantics.
    >
    > *Please post replies here, thx*


    The unspecified_bool_type is a pointer to a member function. The problem
    with the SunCC implementation is that operator bool could be used in places
    you don't want. For instance with operator bool

    shared_ptr<X> xp;
    float f = xp;

    becomes legal code (implicit call of operator bool, followed by promotion of
    bool to float).

    Pointers to member functions are used instead because they are much less
    likely to be result in unintended conversions to other types, but are still
    usable in situations where a Boolean value is needed

    shared_ptr<X> xp;
    if (xp) // implicit conversion to unspecified_bool_type, followed by
    check for NULL
    {
    }

    operator void* is also sometimes used for similar reasons, but operator
    unspecified_bool_type is better I think.

    john
     
    John Harrison, Apr 29, 2004
    #2
    1. Advertising

  3. dru

    dru Guest

    First, thanks for your reply.

    >
    > The unspecified_bool_type is a pointer to a member function. The problem
    > with the SunCC implementation is that operator bool could be used in places
    > you don't want. For instance with operator bool
    >
    > shared_ptr<X> xp;
    > float f = xp;
    >
    > becomes legal code (implicit call of operator bool, followed by promotion of
    > bool to float).


    I can see that, but I don't see a major threat there.


    > Pointers to member functions are used instead because they are much less
    > likely to be result in unintended conversions to other types, but are still
    > usable in situations where a Boolean value is needed
    >
    > shared_ptr<X> xp;
    > if (xp) // implicit conversion to unspecified_bool_type, followed by
    > check for NULL
    > {
    > }
    >
    > operator void* is also sometimes used for similar reasons, but operator
    > unspecified_bool_type is better I think.


    Where can I find in the ARM the description of a conversion from a pointer
    to a bool?


    On a side note, I wish you could do the following with a shared pointer.

    xyz = NULL;

    It would be nice, but I understand the reasons for it's absence.
     
    dru, Apr 29, 2004
    #3
  4. "dru" <> wrote in message
    news:...
    > First, thanks for your reply.
    >
    > >
    > > The unspecified_bool_type is a pointer to a member function. The problem
    > > with the SunCC implementation is that operator bool could be used in

    places
    > > you don't want. For instance with operator bool
    > >
    > > shared_ptr<X> xp;
    > > float f = xp;
    > >
    > > becomes legal code (implicit call of operator bool, followed by

    promotion of
    > > bool to float).

    >
    > I can see that, but I don't see a major threat there.


    Not sure I agree with that. Unexpected converion to a numeric type can be
    very confusing, usually easily fixed when spotted though.

    [snip]

    >
    > Where can I find in the ARM the description of a conversion from a pointer
    > to a bool?


    Sorry I'm not familar with ARM. In the C++ standard it's section 4.12. All
    it says is that any pointer or pointer to member can be converted to a bool
    rvalue, and that null pointers convert to false and other values to true.

    john
     
    John Harrison, Apr 29, 2004
    #4
  5. dru

    dru Guest

    Mr. Harrison,

    Thanks for your help with this. This has been a great
    help.

    Dru
     
    dru, Apr 30, 2004
    #5
  6. dru

    Jeff Flinn Guest

    dru,

    "dru" <> wrote in message
    news:...
    > First, thanks for your reply.
    >

    [spip]
    >
    > On a side note, I wish you could do the following with a shared pointer.
    >
    > xyz = NULL;
    >
    > It would be nice, but I understand the reasons for it's absence.


    how about:

    xyz.reset();

    Jeff F
     
    Jeff Flinn, Apr 30, 2004
    #6
  7. dru

    dru Guest

    > > On a side note, I wish you could do the following with a shared pointer.
    > >
    > > xyz = NULL;
    > >
    > > It would be nice, but I understand the reasons for it's absence.

    >
    > how about:
    >
    > xyz.reset();


    Yep, know all about that. I would prefer = NULL to be like the
    ole' MS style or .clear() to be like the STL folk.

    dru
     
    dru, May 5, 2004
    #7
  8. In article <>,
    (dru) wrote:

    > On a side note, I wish you could do the following with a shared pointer.
    >
    > xyz = NULL;
    >
    > It would be nice, but I understand the reasons for it's absence.


    Actually I think that's a very good suggestion. I think it can be done
    safely. We need a non-explicit shared_ptr constructor taking a pointer
    to a private type (such as unspecified_bool_type). Hmm... I need to
    give that a little more thought, but it looks promising to me.

    -Howard
     
    Howard Hinnant, May 5, 2004
    #8
  9. In message <>, dru
    <> writes
    >> > On a side note, I wish you could do the following with a shared pointer.
    >> >
    >> > xyz = NULL;
    >> >
    >> > It would be nice, but I understand the reasons for it's absence.

    >>
    >> how about:
    >>
    >> xyz.reset();

    >
    >Yep, know all about that. I would prefer = NULL to be like the
    >ole' MS style or .clear()


    But xyz.reset() is just the defaulted-argument special case of
    xyz.reset(pointer-to-something). Either you give it a name that's
    inappropriate for the more general case, or you have a proliferation of
    member functions with overlapping effects.

    >to be like the STL folk.


    who can't even decide whether a string has a .length() or a .size() ;-)
    --
    Richard Herring
     
    Richard Herring, May 7, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Richard Latter
    Replies:
    2
    Views:
    2,931
    Julie
    May 17, 2004
  2. Steve Knight
    Replies:
    2
    Views:
    806
    Steve Knight
    Oct 10, 2003
  3. Toby Bradshaw
    Replies:
    6
    Views:
    1,818
    Kai-Uwe Bux
    Jun 2, 2006
  4. Colin Caughie
    Replies:
    1
    Views:
    766
    Shooting
    Aug 29, 2006
  5. Misiu
    Replies:
    3
    Views:
    2,454
    Misiu
    Jan 31, 2007
Loading...

Share This Page