On Wed, Oct 6, 2010 at 12:09 PM, michi7x7 wrote:

Hi

...

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

what do you mean? .at<>() is a template member function. at_c<N>() is from Boost.Spirit and uses .at<>() internally (i guess).

it doesn't seem so: vector bfv; clog << bfv.at<0>() << endl; //ERROR error: ‘struct boost::fusion::vector’ has no member named ‘at’

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

...

That's not possible, because the return-type has to be known during compile-time. You can't do this with "normal" arguments.

presicely, I am asking for .at<N>() (I just noticed that boost::tuples have .get<N>() member) Thanks for the answer, Alfredo

On Wed, Oct 6, 2010 at 12:13 PM, Simonson, Lucanus J < lucanus.j.simonson@intel.com> 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 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

On Wed, Oct 6, 2010 at 1:21 PM, Frank Mori Hess wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday 06 October 2010, alfC wrote:

...

Hi,

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 stuff(1.2, 3, "hola"); stuff.at<2>(); //returns "hola", just like at_c<2>(stuff);

Wouldn't that require template specializations of the "at()" member template for its differing return types? IIRC, C++ doesn't let you specialize template members of template classes.

It does not seem to be a technical problem, tuples have member functions tuples t; t.get<2>(); // a string

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkys2mAACgkQ5vihyNWuA4Wd+wCff6IeuTbsJj0GVqPrqaGanKEG 9ogAoM/nwd7GCdR4IzYR2i5lBLhfyx1z =ojtF -----END PGP SIGNATURE----- _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe Boost Users beigetreten sind. Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an boostusers@googlegroups.com. Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an boostusers+unsubscribe@googlegroups.com . Besuchen Sie die Gruppe unter http://groups.google.com/group/boostusers?hl=de, um weitere Optionen zu erhalten.

On Fri, Oct 8, 2010 at 7:23 AM, Frank Mori Hess wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Thursday 07 October 2010, OvermindDL1 wrote:

...

To be frank, you should *never* have any function be a member function unless it absolutely cannot be created externally, you will have better compile times, better encapsulation,

In the case he's talking about (similar to Boost.Tuple get()), a template parameter has to be specified for the function, which means ADL won't work, so you have to fully qualify a free function call (or use "using").  What's less annoying to use?

boost::tuples::tuple tup;

tup.get<1>();

or

boost::tuples::get<1>(tup);

...

and it prevents you from doing nice things like the above.

And of course, adding a member function doesn't prevent anything, it's not an either-or question.  For example, having member swap() methods doesn't prevent a free-function swap() from existing.

But using a function where you pass in, say, a fusion container, but the function calls a member function on it, but you pass an adapted, say, boost::array or some other custom type that was adapted to a fusion container, will fail to compile. Not putting member functions like that in the first place prevents someone from making that mistake.