Re: [boost] [type_at] Variadic template utility

Subject: Re: [boost] [type_at] Variadic template utility
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-05-26 07:39:30

On 26/05/2011 13:19, Larry Evans wrote:
> On 05/26/11 04:47, tymofey wrote:
>>> Robert Jones<robertgbjones_at_[hidden]>
>>> On Thu, May 26, 2011 at 8:34 AM, tymofey<tymofey_at_[hidden]>  wrote:
>>>
>>>> While experimenting with varidic templates of the upcoming standard i
>>>> discovered that quite often one would need to extract a type from parameter
>>>> pack at specified position.
> [snip]
>>> Forgive me if I'm missing the point, but isn't this essentially Boost.MPL's
>>> 'at' metafunction?
>>>
>>> - Rob.
>>
>> It is, but without the need to drag in mpl::vector with the limitations it imposes.
>>
> Could you please describe those limitations, other than the one for
> maximum arity, which, IIUC, is modifiable by redefining the macro:
>
>    BOOST_MPL_LIMIT_VECTOR_SIZE
>
> ?  Also, IIUC, one reason for using the macro, and the preprocessor,
> is to speed compile time by reducing the number of template
> instantiations. Thus, maybe one advantage of mpl::at vs your type_at
> is compile time. You might check that somehow.

You cannot expand a template parameter pack to instantiate a 
non-variadic template.

Typically, this

template<typename... T>
struct make_vector
{
     typedef boost::mpl::vector<T...> type;
}:

doesn't work.

GCC gives the error:
sorry, unimplemented: cannot expand 'T ...' into a fixed-length argument 
list

And I believe the standard doesn't require it just because it would be 
difficult to implement in GCC's codebase.