What is boost's unspecified_bool_type?

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" <dru-news@redwoodsoft.com> wrote in message
news:6c43e774.0404281424.77082c44@posting.google.c om...[color=blue]
> Every time I think I know or understand C++ with some
> confidence, I see something that changes that.
>[/color]

I know that feeling.
[color=blue]
> 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*[/color]

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

First, thanks for your reply.
[color=blue]
>
> 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).[/color]

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

[color=blue]
> 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.[/color]

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" <dru-news@redwoodsoft.com> wrote in message
news:6c43e774.0404291112.1c136798@posting.google.c om...[color=blue]
> First, thanks for your reply.
>[color=green]
> >
> > 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[/color][/color]
places[color=blue][color=green]
> > 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[/color][/color]
promotion of[color=blue][color=green]
> > bool to float).[/color]
>
> I can see that, but I don't see a major threat there.[/color]

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

[snip]
[color=blue]
>
> Where can I find in the ARM the description of a conversion from a pointer
> to a bool?[/color]

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

Mr. Harrison,

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

Dru

dru,

"dru" <dru-news@redwoodsoft.com> wrote in message
news:6c43e774.0404291112.1c136798@posting.google.c om...[color=blue]
> First, thanks for your reply.
>[/color]
[spip][color=blue]
>
> 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.[/color]

how about:

xyz.reset();

Jeff F

> > On a side note, I wish you could do the following with a shared pointer.[color=blue][color=green]
> >
> > xyz = NULL;
> >
> > It would be nice, but I understand the reasons for it's absence.[/color]
>
> how about:
>
> xyz.reset();[/color]

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

In article <6c43e774.0404291112.1c136798@posting.google.com >,
dru-news@redwoodsoft.com (dru) wrote:
[color=blue]
> 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.[/color]

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

In message <6c43e774.0405041624.76eb466a@posting.google.com >, dru
<dru-news@redwoodsoft.com> writes[color=blue][color=green][color=darkred]
>> > 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.[/color]
>>
>> how about:
>>
>> xyz.reset();[/color]
>
>Yep, know all about that. I would prefer = NULL to be like the
>ole' MS style or .clear()[/color]

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.
[color=blue]
>to be like the STL folk.[/color]

who can't even decide whether a string has a .length() or a .size() ;-)
--
Richard Herring