Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-12 16:06:15

----- Original Message -----
From: "William E. Kempf" <wekempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, December 12, 2002 5:31 PM
Subject: Re: [boost] Formal review: Optional library

>
> Fernando Cacciola said:
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> >> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
> >> > From: "Peter Dimov" <pdimov_at_[hidden]>
> >> > optional<> is not intended to replace _all_ situations were optional
> >> values
> >> > are used.
> >> > It is itended to be used on those situations were pointers are
> >> difficult
> >> to
> >> > use;
> >> > but I expect programmers to keep using pointers were appropriate.
> >> For example, as I said before, optional arguments to a function
> >> should
> > not
> >> > be coded
> >> > with optional<> but with conventional pointers.
> >>
> >> Actually (just a minor observation)
> >>
> >> void f(optional<T> /*const &*/ opt);
> >>
> >> is different than
> >>
> >> void f(T const * pt);
> >>
> >> as the latter might potentially store 'pt' while the former cannot.
> >>
> > ? You mean that the code inside f() could hold onto 'pt'?
> > Well, yes it can... but that would be nasty.
> > It is supposed to know that ownership is not being handed in.
> > The use of a pointer is reserved to convey optionality.
>
> It is?  Then how do you ever transfer ownership ;).
>
Hmm... OK, I take that back.
A function can use a pointer to optionally take ownership of an object.
So optional<T> as an argument could communicate that this is not the case,
which is what Peter meant (I think...)

Fernando Cacciola