[fusion] .at<N>() template member in containers?
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<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? Thank you, Alfredo
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. fusion::vector<double, int, std::string> stuff(1.2, 3, "hola"); stuff.at<2>(); //returns "hola", just like at_c<2>(stuff); at_c<N>() is from Boost.Spirit and uses .at<>() internally (i guess). 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. By the way, does anybody know where the name given "at_c" (I mean the '_c') comes from? Well, I guess this is for "container" ? Thank you, Alfredo Regards,
michi7x7
On Wed, Oct 6, 2010 at 12:09 PM, michi7x7 <mailing-lists@michi7x7.de> 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<double, double, double> bfv; clog << bfv.at<0>() << endl; //ERROR error: ‘struct boost::fusion::vector<double, double, double, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_>’ 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
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. Regards, Luke
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<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
-----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<double, int, std::string> 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkys2mAACgkQ5vihyNWuA4Wd+wCff6IeuTbsJj0GVqPrqaGanKEG 9ogAoM/nwd7GCdR4IzYR2i5lBLhfyx1z =ojtF -----END PGP SIGNATURE-----
On Wed, Oct 6, 2010 at 1:21 PM, Frank Mori Hess <frank.hess@nist.gov> 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<double, int, std::string> 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<int, double, string> 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<boostusers%2Bunsubscribe@googlegroups.com> . Besuchen Sie die Gruppe unter http://groups.google.com/group/boostusers?hl=de, um weitere Optionen zu erhalten.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 06 October 2010, Frank Mori Hess wrote:
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.
Err, nevermind. I just looked at how boost.tuple implements tuple::get. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkys4H8ACgkQ5vihyNWuA4Uw2gCgxt/8V1Ou6OC3VLBke0dqNyTZ foMAoIVLI6dG0SZVy8injO+ZO72TO7Ay =2ixb -----END PGP SIGNATURE-----
On Wed, Oct 6, 2010 at 12:56 PM, alfC <alfredo.correa@gmail.com> 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<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);
No, because things like std::vector is an implementation class, hence it can be done in any way they want, however fusion does not have that luxury, for example, boost::array is defined as a fusion container, so you can do something like this: template<typename T> void printSecondElement( const T &t ) { std::cout << *next(begin(t)); } Now, you can do something like this with it: fusion::vector<int,double,char> f(42,3.14,'X'); printSecondElement(f); Or you can do this: boost::array<int,3> a(1,2,3); printSecondElement(a); Or even this: struct MyType { char a; float f; } BOOST_FUSION_ADAPT_STRUCT( MyType, (char, a) (float, f) ) MyType t('r', 3.14); printSecondElement(t); And guess what, it prints the second element of each thing, whether a fusion::vector, a boost::array, or some custom MyType. Hence, it is impossible to have at be a member function. 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, and it prevents you from doing nice things like the above.
-----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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkyvG24ACgkQ5vihyNWuA4URbgCgrVSiuhQK+aMudVw+HJEJkNR/ A68AoLhYY3Df/cBz45AKhC2BBgL3GpvD =Iezo -----END PGP SIGNATURE-----
On Fri, Oct 8, 2010 at 7:23 AM, Frank Mori Hess <frank.hess@nist.gov> 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.
participants (2)
-
alfC -
Alfredo Correa
-
Alfredo Correa -
Frank Mori Hess -
michi7x7 -
OvermindDL1 -
Simonson, Lucanus J