Boost logo

Boost :

From: Mat Marcus (mmarcus-boost_at_[hidden])
Date: 2003-09-17 12:19:57

--On Wednesday, September 17, 2003 1:05 PM -0300 Fernando Cacciola
<fernando_cacciola_at_[hidden]> wrote:


> Mat Marcus <mmarcus-boost_at_[hidden]> wrote in message
>> I imagine that it could be useful to have something like a universal
>> 'none' object that could be passed to functions expecting
>> optionals. I would expect its effect to be the same as passing the
>> anonymously constructed optional in the line of code directly
>> above. That is I would like to write:
>> out_edge_iterator end(none); file://optional::none?
> Well, something like this can be done, though I wonder why couldn't
> you just use the default constructor as in:
> out_edge_iterator end;
> which is the cannonical way to introduce an uninitialized optional<>.

Sorry, my example was ill chosen. Let me try again. I am actually
trying to simplify the implementation of out_edges whose signature
(leaving out some qualifications) happens to be:

  std::pair<out_edge_iterator, out_edge_iterator>

At the end of my out_edges implementation I must return a pair of my
iterator_adaptor based iterators that I will ask you to recall have a
Base of optional<edge_descriptor>. So my code looks something like:

  return std::pair<out_edge_iterator, out_edge_iterator>(
    calculated_begin, optional<out_edge_iterator>());

I was wishing to be able to replace the second parameter with, say,
none. In general I suggest that functions that accept optional
parameters should be as easy to use. I think that the new version of
optional makes it very easy to pass such functions a T, but it remains
slightly awkward to supply a parameter of none. I could probably think
of other uses for 'none', perhaps "== none" as an alternative to
is_initialized(), but that's another question.

>> * Safe optional<bool>'s as tri-bools would be quite useful to
>> me. I personally would sacrifice the convenience of testing
>> without using is_initialized() to gain tri-bools but I don't want
>> to cover old territory. Perhaps there's some other way of making
>> optional<bool>'s safer to use. What would you think of, say, using
>> enable_if (or better disable_if) to disable implicit bool
>> conversion and operator! for when T == bool (or when T already
>> is_convertible to bool)?
> I decided not to treat optional<bool> specially since as Doug just
> said there is boost::tribool.
> In order to use optional "safely" and uniformly in the presence of
> [T=possibly bool] all you have to do is not to use the safe_bool
> feature. For instance, you can consistently use the double-bang
> idiom:
> if ( !!opt ) ....

Sure, there are safe idioms to follow. What concerns me is when, say,
some comes to maintain a piece of code and is not familiar with idioms
such as !!. Or when the !! is inadvertently left out. I'd prefer
compiler support against such cases. But I understand your rationale.
I suppose I could use optional_base, implicit construction, assignment
from T and a constructor from 'none' to get exactly what I want.

Thanks again for your recent set of changes.

 - Mat

Boost list run by bdawes at, gregod at, cpdaniel at, john at