Boost logo

Boost :

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$
> Fernando Cacciola wrote:


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

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

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

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.


Fernando Cacciola

Boost list run by bdawes at, gregod at, cpdaniel at, john at