Eric Friedman <ebf@[...].net>  wrote in message news:bjqpum$2nm$1@[...]..
>  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 argumen
t
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






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