From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-08-30 22:19:00
On Thursday 30 August 2001 06:38, you wrote:
> > > Supporting direct initialization has the drawback that both statements
> > > below become equivalent, which I find confusing:
> > >
> > > optional<int> v ;
> > >
> > > v = 3 ;
> > > *v = 4 ;
> > I personally don't mind this equivalence. It's the same thing one deals
> > when using any or a variant type, except that instead of *v we have
> > like any_cast<T>(v) or v.as<T>().
> Not quite so. AFAIK, any_cast<> and .as<> are rvalues.
It's try that any_cast<> returns an rvalue, but .as<> returns an lvalue. The
definition could go either way, of course, but perhaps returning an rvalue is
safer because it guarantees type safety...
> There is a problem, anyway, in supporting a non-explicit direct
> optional<double> opt = foo();
> if ( opt == 3.14 ) // This will automatically create a temporary for the
> 3.14, thus violating the strict pointer semantic I am trying to keep
How is comparison between optional<T>s defined?
> > > optional<int> v ( 3 ) ;
> > > *v = 4 ;
> > This might be a good compromise. It looks strange when you name v (why
> > it be optional if you have a value for it?), but it's not quite so
> > strange in a return statement.
> Perhaps I am biased by the coding style of having only one return statatent
> at the end. So direct initialization won't usually be of much help to me in
> a return statement.
> There is a situation, though, in which direct initialization is
> *significantly* useful:
> void foo ( optional<point> where ) ;
> with direct initialization: foo ( optional<point>( point(2,3) ) ) ;
> currently: optional<point> p ; *p = point(2,3) ; foo(p);
I'm not sure I understand why one would pass an optional parameter in this
way, but if one does it then surely direct initialization would be a boon.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk