Mat Marcus <[EMAIL PROTECTED]> writes:
> ### Question 2
>
> In another case I am trying to use optional with iterator_adaptor
> (1.30.x version).
Whoa; don't do that ;->
It'll hurt (comparitively speaking).
> Here I would like the "base" for my iterator_adaptor to be, say,
> boost::optional<Baz>. The value_type is to be Baz. But
> iterator_adaptor chooses the signature of the eventual iterator
> class for me.
What do you mean by "the signature of the... class"?
> As a result, clients of my iterator have to pass
> ::boost::optional<Baz>'s to the constructor. But I would also like
> them to be able to pass plain Baz's.
> That is, I want a non-explicit constructor for optional.
No, you want the ability to add your own constructor to adapted
iterators. You need control over the library components *you* design,
and and are trying to remedy that by influencing the design of
optional. Unfortunately you came to the wrong iterator_adaptor.
Please see the CVS one ;-)
> In this case I don't have the freedom to create another constructor
> to easily workaround this problem. Reading back over the formal
> review threads for optional, I noticed that the reason for the
> explicit constructor was to support the pointer-like nature of
> optional. Right now I am questioning whether the pointer-like
> semantics is worth it to me. I would probably prefer that clients
> type more to test whether a value is initialized so that they can
> type less to call a function that takes an optional as a parameter
> when they have a value to pass in.
Well, that's a slightly different issue and you may be right. On the
other hand, you can always define a type which implements those
implicit constructors:
template <class T>
struct implicit_optional : optional<T>
{
implicit_optional() {}
implicit_optional(optional<T> const& x) : optional<T>(x) {}
implicit_optional(T const& x) : optional<T>(x) {}
};
You could use that in your interfaces.
> Sorry if this has already been covered, but here my question is:
> Have you experimented with a variant of optional that drops the
^^^^^^^^^^^^^^^^^^^
Whoa; you're making me dizzy with discriminated union-ness!
> pointer-like semantics, allowing implicit construction and
> disallowing implicit safe-bool conversion, and if so what did you
> learn that made you favor the current set of tradeoffs?
>
> Thanks,
> Mat
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
