Boost logo

Boost :

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
>
> with
>
> > when using any or a variant type, except that instead of *v we have
>
> something
>
> > 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
> initialization:
>
> 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
> strict.

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
>
> would
>
> > 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.

        Doug


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk