Boost logo

Boost :

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

--On Tuesday, September 09, 2003 6:43 PM -0300 Fernando Cacciola
<fernando_cacciola_at_[hidden]> wrote:

> Hi boosters,
> Following the suggestions that had been made since Optional's
> acceptance I've updated the library.
> I will upload the new version on main CVS tomorrow noon unless
> someone objects.

Thanks a lot for updating optional! The new version really simplifies
my optional usage to the point where I'm willing to commit to it in my
current project.

I have a little bit of additional feedback. I hesitated a little bit
before posting to the main list for fear of starting another
should-it-be-a-pointer thread, but I hope we can avoid traveling down
that thread again. As I mentioned earlier, one of my use cases is to
use optional together with graph and iterator_adaptor 1.30.x. Here are
a few things that I've noticed:

   * Tie works nicely now. That is I can now happily write:

using namespace boost; // for e-mail conciseness only

    out_edge_iterator out_i, out_end;
tie(out_i, out_end) = out_edges(vertex, graph);

   * The out_edge_iterator is implemented as an iterator_adaptor with
a Base = optional<edge_descriptor>. With the changes to optional I can
now enjoy transparent construction of my out_edge_iterator's:

out_edge_iterator i(someEdge);
// instead of i(optional<out_edge_iterator>(someEdge));

This is rather convenient. It is a little bit less convenient to
construct the end out_edge_iterator. In my case end is represented by
an iterator with uninitialized optional state. Here I apparently have
to write:

out_edge_iterator i(optional<out_edge_iterator>());
//longer in its fully qualified glory

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); //optional::none?

You could think of it as analogous to NULL for pointer types (but lets
not talk about pointers).

   * 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)?

 - Mat

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