[boost] Re: [optional] update

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-09-11 17:15:17

Eric Friedman <ebf_at_[hidden]> wrote in message news:bjqpum$2nm$1_at_sea.gmane.org...
> Fernando Cacciola wrote:

[sniped]

> > If in_place<> uses its first template parameter to designate the target
> > type, then it will be used exactly as you show above and then it could be
> > adopted by variant as is.
>
> I would prefer this to be honest...
>
OK.

>
> Right. Well I don't have any use for this, but I can see why it would be
> useful. If we can keep it without significant effort, then I guess we
> should.
>
Agreed.

>
>
> > Alternatively, we could have two flavours of this:
> >
> > in_place(x,y,z) -> x,y,z are constructor parameters for any type.
> > typed_in_place(T,x,y,z) -> are constructor parameters for the type T.
> >
> > Notice that if we want to use the same function for both cases
> > there must be a way to tell whether the first parameter is the target type
> > or the first contructor argument type.
>
> I agree we need two flavors, but I don't know if they need different names.
> For instance, given
>
>   template <typename T1> void f(T1);
>   template <typename U, typename T1> void f(T1);
>
> both of the following calls are valid and unambiguous:
>
>   f(1234);
>   f<T>(1234);
>
>
Yes, of course.
The ambiguity I was concerned with ocurred in case a user wanted to use partial explicit
instantiation to define the type of the arguments, as in:
float num ;
f<int>(num);

But I guess we can simply state that if an explicit partial instantiation is used the _first_
template parameter will correspond to the target type and never to the first factory argument
type. After all, the above can always be achieved via a cast:

float num ;
f( static_cast<int>(num));

> I would think we could apply this idea to in_place. The only 'problem' is
> that it leads to a doubling of needed overloads. So I guess we should
> consider whether the 'untyped' version you've developed is worth retaining.
>
OK, I think that the 'polymorphic' in_place as you've shown above is the right choice.

The double overloads are not so problematic, I think, since optional<> users
will most likely never use the explicit form.

I'll update the code tomorrow so you can adopt it.

Regards,

Fernando Cacciola