From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-12 16:06:15
----- Original Message -----
From: "William E. Kempf" <wekempf_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...)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk