--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
