Re: [boost] Re: Optional, tie, and iterator_adaptor

[Mat Marcus]

--On Friday, August 29, 2003 2:56 PM -0400 David Abrahams 
<[EMAIL PROTECTED]> wrote:

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"?
Sorry: meant to say "... of the eventual iterator class's constructor"

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 ;-)
I mentioned iterator_adaptor 1.30.x as an example of a case where "the 
obvious workaround" is not possible. But even where I could add 
"convenience" constructors I'm still asking whether an optional-like 
class that offered an implicit constructor (and also worked with tie) 
might not be useful.

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.
And then slice it back to option internally to avoid bool weirdness? 
Might work out. Got any good ideas to help use optional with tie?


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!
Hehe.


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?
Still curious about this as the temptation remains to explore a 
different part of the design space...

- Mat

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost