Re: [boost] possible addition to operators library

From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2003-02-26 06:57:05

Hi all,

Sorry I've been off air for a bit. I'll try to answer as much as I can in
this email.

Daniel Frey wrote:
> I also think it would be fair to mention Dave as a contributor, too,
> as he provided the way to reduce the overhead.

Of course, that bit was still there from the first time through, also
whoever came up with the original "unspecified-bool-type" idiom needs
acknowledged as well.  No offence intended, merely laziness.  Sorry.

David Abrahams wrote:
> "Sam Partington" <Sam.Partington_at_[hidden]> writes:
>> Also seems to me that anyone who declares a global template operator!
>> deserves some problems!
> I don't know why you think so.
Well, I don't mean that they deserve to be stoned to death or anything!  But
they are going to be seeing some strange things anyway.  I don't think us
providing with them another operator is going to cause them any more issues.

>> So, now with David's suggestion, I've attached what I propose.
>>
>> I've tested to a small extent on MSVC6 and gcc 2.95, which are all
>> the compilers I have access to now.
>>
>> (First time I've used a patch file so apologies if I've messed it up)
>
> It's very nice, but you left out the most-important parts:  patches
> for the docs and testsuite.

How did I know someone would pull me up on that :-) I'm working on them, I
just need to get a handle on the test suite first.  I was fairly sure that
the code patch was going to be enough to get us discussing for now.

Douglas Paul Gregor wrote:
> myclass m;
> yourclass y;
>
> if (m == y) {
>   // what's this mean?
> }
>
> This is the reason boost::function has poisoned operator== and
> operator!=.

Doesn't this require two user defined conversions, which stops this from
being possible?  However I agree we should avoid possible problems like
this.   The idea behind "unspecified-bool-type" is to return an obscure type
that can't be accidentally used where not expected -  so I would say make it
as obscure as possible.  To me this means a private nested struct.  Which
I'll come to in a minute.

Daniel Frey wrote:
> That won't work as you made it a nested struct so it is still
> different for all instantiations. I think Dave meant to go for this
> one:
This was intentional for the reason I've just stated above.  I don't see
this as any efficiency problem, as certainly on the two compilers I've tried
there was no instantiation of safe_bool at all, without optimisations.  With
optimisations on all of the code inlined into the ideal x != 0.  Ok on
_some_ compilers this may be an issue, but that goes for just about all
things in boost.

As for making safe_bool reusable, I can only see one possible reason.  Where
someone would want to make if (x) a valid construct but not if (!p).  Is
this enough reason to allow it?  If so then it does not really belong in
boost/operators.hpp, more likely boost/utitlity.hpp.

Is there another alternative to this?  How about this:

  typedef void (bool_testable<T,B>::*unspecified_bool_type)() const;
  operator unspecified_bool_type() const
  {
   return !static_cast<const T&>(*this) ? 0 :
reinterpret_cast<unspecified_bool_type>(&bool_testable<T,B>::operator
unspecified_bool_type);
  }

Does this have any issues that I can't see?   Ideally we could avoid the
reinterpret_cast, but how do you express the type of a user-defined
conversion operator for the type you're trying to express? Beats me!

Sam