Boost :

fcacciola_at_[hidden]

--
   :-)
"Alberto Barbati" <abarbati_at_[hidden]> escribió en el mensaje
news:atf8kh$gvr$1_at_main.gmane.org...
> Fernando Cacciola wrote:
> >>As an example, currently the C++ standard includes
> >>    T & stack<T>::top(), with precondition !(stack.empty()).
> >>
> >>Instead, it could be
> >>    may_be<T> & stack<T>::top();  // no precondition required
> >>
> >>
> >><set> could be improved also, instead of:
> >>    pair<iterator, bool> set::insert(const value_type & x)
> >>
> >>we would use
> >>    may_be<iterator> set::insert(const value_type & x)
> >
> > Those are interesting examples! Thanks.
> > They can all be paralleled with optional<> whatever the model and
interface
> > we choose.
> > Which can of shows that the concept is useful.
>
> If I can say it, I don't think that they are really good examples.
>
> The stack::top signature is wrong, it should return a value and not a
> reference and thus it may require a copy of the returned object. This
> makes the proposed signature is potentially less efficient. Moreover,
> the result of top() could not be used by the caller to modify the
> top-most element. For this reason, a more correct signature would be
>
I think Dave just made a typo.
His point still holds: currently, if you call top() on an empty stack you
get undefined behaviour
right from within the call.
If opt() returned an optional<>, you would have undefined behaviour only if
you
effectively try to access the value.
The different is the point were you get the undefined behaviour.
Off the top of my head, I can image how this can be useful on some lazy
evaluation systems.
>      may_be<T&> stack<T>::top();
>
> but, unfortunately, I don't think it's legal.
>
It isn't, right.
>
> The proposed signature of set::insert is a downgrade and not an
> improvement. Even if the element is not inserted, I still may want to
> have the iterator. In order to perform its operation, insert() will have
> to compute such iterator, so what's the point in discarding it?
>
You're right here.
The iterator is always valid so it is useful on itself.
In fact, I now remember that Peter Dimov made exactly this correction
back then when I showed exactlky this example as a use case for
optional<>
Fernando Cacciola