alfC wrote:
>  Excuse my simple minded questions. Sometimes by asking this question
> (often with negative answer) I understand more on the design of the
> Boost libraries.

>
> Besides possible redundancy, why is that the fusion containers, for
> example fusion::vector, doesn't have a template member function to
> extract elements?
>

>  fusion::vector<double, int, std::string> stuff(1.2, 3, "hola");
>  stuff.at<2>(); //returns "hola", just like at_c<2>(stuff);
>

> Wouldn't it be more consistent with std::vector v, v[2] or v.at(2);
>

> By the way, does anybody know where the name given "at_c" (I mean the
> '_c') comes from?

There is a style convention in boost to prefer non-member non-friend functions over member functions unless there is an invariant of the class that maintained by a member function with direct access to private members.  There are a number of articles written on this subject by Scott and Bjarne and others.

The _c means the template parameter is a compile time constant rather than a type.  Typicallly the version of the template that accepts the type, eg. true_type, dispatches to the version named _c that accepts the compile time constant unpacked from within the type.  This is done primarily to work around bugs in older MSVC compilers as far as I know, that comiple templates that depend on compile time constants earlier than templates that depend on types and therefor results in different SFINAE behavior for the two, where the behavior of the one accepting compile time constants is the one we want/correct behavior.