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

[Mat Marcus]

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

Mat Marcus <[EMAIL PROTECTED]> writes:

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?
I didn't have that in mind, no.  Why slice when you can avoid a copy
instead?  and what is "bool weirdness"
I meant something like this. It seems that optional takes some pains 
to mimic pointer semantics. In particular testing whether an optional 
== 0 is suppose to be equivalent to calling initialized(). Implicit 
constructability seems in conflict with this idiom, so I was thinking 
it might be a good idea to avoid using something like 
implicit_optional except in interfaces. But it seems kind of painful 
to bend optional in this direction. Perhaps I will just try creating a 
new class, borrow some implementation techniques from optional.


Might work out. Got any good ideas to help use optional with tie?
Seems to me you could use a similar shim, as long as it had a const
assignment operator:
           tie(shim(foo), shim(bar)) = ... ;

Not very generic, but it should work out.

Interesting. Just thinking out loud so maybe I'm off in space, but 
maybe something like

  tie_optional(foo, bar) = ... ;

could create a tuple of appropriate shims. Of course then I would 
really rather spell such a tie_optional as tie <g>.

- Mat

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