Boost logo

Boost :

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.


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