RE: [boost] Re: More on the optional class.

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-09-17 10:35:07

----- Original Message -----
From: Daryle Walker <darylew_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, September 14, 2001 9:26 PM
Subject: [boost] Re: More on the optional class.

> on 9/13/01 8:18 PM, Fernando Cacciola at fcacciola_at_[hidden] wrote:
>
> [SNIP]
> > I also made up my mind about how to let the user test if a given
optional is
> > initialized or not.
> > Previously, optional<> used operator void*() to allow expressions of the
> > form:
> >
> > if ( opt ) or if ( opt != NULL )
> >
> > After *a lot*  of consideration, I decided to support only the
'bang-bang'
> > idiom:
> >
> > if ( !!opt ) means initialized.
> > if ( !opt) means uninitialized.
> >
> > I just hope enough people is aware and fond of this very useful
technique,
> > because it removes all the problems with the other approaches.
> > The new optional.hpp header contains a small rational for this design
> > decision.
> [TRUNCATE]
>
> What about this alternative:
>
> You had an "operator void*()" defined for Boolean tests, to avoid the
> integral conversions that "bool" has.  However, this property isn't just
> limited to void pointers, it will work for any pointer type.  Since your
> class acts kind-of like a smart pointer, why don't you define the Boolean
> operation with "operator T*()" instead!  You'll get "operator !()" for
free
> and you could connect it with an "operator *()" and "operator ->()".
>
Thanks for commenting on this!

This was one of the alternatives I considered.
Before I explain why I didn't adpoted it, I need to state my overall
position about these matters.
I've been using this class for a long time, and it came to be a really
fundamental piece of engineering in my every day programming. I use it very
widely because it presents a clean idiom to some very common tasks.
Now, I may be biased by the fact that this is my own creation, but I
envision that eventually, every programmer will use it as extensively as I
currently do.
Because of its potential *wide* usage, I'm forced to consider all the
possible side efects and 'traps' that an average programmer might not
account for; even if while doing this, I end up being too paranoic; but I
believe that in the end it will help make programs using optional less
faulty.

With respect to the 'operator T*()', I haven't adopted it becuase it would
allow the following:

  optional<int> opt1 = 1234 ;
  optional<int> opt2 = 1234 ;

  if ( opt1 == opt2) // this will compile OK if there is an 'operator T*()',
but won't evaluate as expected.

the above boolean expression is ill-formed w.r.t the optional specification,
but there is no compile-time nor runtime indication of that.  I decided to
support only those idioms that would prevent the mistakes as above. AFAICT,
these are (1) operator !(), (2) a friend 'T* get(opt)' function (thanks to
Peter Dimov!).

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com