Boost logo

Boost :

From: Mat Marcus (mmarcus-boost_at_[hidden])
Date: 2003-08-29 16:00:30


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

> Mat Marcus <mmarcus_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk