Re: [Boost-users] [fusion] .at<N>() template member in containers?

Subject: Re: [Boost-users] [fusion] .at<N>() template member in containers?
From: Alfredo Correa (correaa_at_[hidden])
Date: 2010-10-06 16:02:52

On Wed, Oct 6, 2010 at 12:13 PM, Simonson, Lucanus J <
lucanus.j.simonson_at_[hidden]> wrote:

> 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.
>
>
I got confused by the wording. But I think I get the idea, it something can
be a free function in the first place, then make it a free function.

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

Do you mean that If it not were for the old MSVC, we could have a nice
at<N>(v) syntax instead of at_c<N>(v)?

Thanks for the answer,
Alfredo