Variadic templates
in [C++]
|
Prev: ANN: Library dependency graphs tool status update and questions
Next: warning: ... has a field ... whose type uses the anonymous namespace
From: cppljevans on 30 Nov 2008 06:29 On Nov 30, 2:56 am, cppljev...(a)gmail.com wrote: > On Nov 27, 10:51 pm, Larry Evans <cppljev...(a)suddenlink.net> wrote:> On 11/26/08 14:47, Daniel Kr�gler wrote: > > [snip] [snip] > > That extra overhead was mentioned in post: > > > http://lists.boost.org/Archives/boost/2002/01/23881.php > > However, the following post: > > http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/... > > suggest that using a hierarchy of types (on element in hierarchy > for each member variable) could, in some cases, result in less > memory use instead of more. OOPS. I had assumed KK's conclusion about the space advantage of the hierarchy of classes was correct; however, Boris' post: http://groups.google.com/group/comp.lang.c++.moderated/msg/62173ac166a993d 3 in another thread, indicates KK's conclusion was wrong, AFAICT. Sorry for noise. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Faisal Vali on 1 Dec 2008 02:08 On Nov 30, 5:29 pm, Boris Rasin <rasin.bo...(a)gmail.com> wrote: > On Nov 30, 10:57 am, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> > wrote: > > > Maybe the introduction of variadic members opens up a can of worms ;-) > > Perhaps I am missing something obvious, but to me the following two > expansion cases seem extremely similar, even if not identical: > > template <typename ... Args> > struct store > { > store (Args ... args); // Case 1, allowed by current draft > Args ... members; // Case 2, NOT allowed by current draft > > }; Boris - You make some very good points. If you are truly interested in seeing this move forward - email "William M. (Mike) Miller"wmm[AT&] edg[dot&]com - with a defect report. I would state something along the lines of - the purpose of variadic templates is to simplify library writing (I would also include Krugler's rationales mentioned in previous posts) - yet this current limitation appears to significantly complicate the authoring of "bind" like solutions (which as the original implementers state is still quite complex - but as you have tried to show, it need not nearly be as complex). I would also consider addressing the following in the DR (proposal): store<int,char> s(1, '2'); // should this be allowed (sure - why not?) - covered by the list in 14.5.3 f(s.members...); What are the copy, and move semantics of classes with these member packs (something template and function parameter packs do not need to deal with)? Also can this effect the triviality or literality of a class? store<int,char> s2(s); s = s2; store<int,char> fun(); And it always helps to propose the standardese that would be required to implement the fix. At a minimum you would need to create an entry for "member template pack" in 14.5.3 - and also add some grammar to 9.2. You might also want to copy Doug Gregor - u can google him for his email address. Apparently there is some precedence to this as they did something similar when eric niebler noted an issue with variadic template template parameters (albeit a smaller change in my opinion). If you can convince them to implement it in conceptgcc (or better yet help them) - it might vastly improve the chances of this getting accepted in C++0x. At least this way it will get some serious consideration. good luck :) (& let me know if I can help in any way) Faisal Vali Radiation Oncology Loyola -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Faisal Vali on 1 Dec 2008 03:09 On Nov 30, 5:29 pm, Boris Rasin <rasin.bo...(a)gmail.com> wrote: > On Nov 30, 10:57 am, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> > wrote: > > > Maybe the introduction of variadic members opens up a can of worms ;-) > > Perhaps I am missing something obvious, but to me the following two > expansion cases seem extremely similar, even if not identical: > > template <typename ... Args> > struct store > { > store (Args ... args); // Case 1, allowed by current draft > Args ... members; // Case 2, NOT allowed by current draft > > }; > FYI: if your proposal is accepted (i.e. to allow member template packs) then look how much simpler and more intuitive the definition of tuple also becomes - (specifically it doesn't try and emulate tuple- like behavior while being implemented in terms of a recursive list- like structure). template<class ...Args> struct tuple { Args ... args; tuple(add_const_reference<Args>::type ... args) : args(args) ... { } template<class ...Args2> tuple(const tuple<Args2...>& other) : args(other.args) ... { } template<typename... VValues> tuple& operator=(const tuple<VValues...>& other) { args = other.args...; // grammar allowed currently by 14.5.3/4 - use , as a separator return this; } }; template<typename...Args1, typename...Args2> bool operator==(const tuple<Args1...>& t1, const tuple<Args2...>& t2) { return true && (t1.args == t2.args) ...; // also currently allowed - use && as separator } template<typename ... Args1, typename... Args2> bool operator<(const tuple<Args1...>& t, const tuple<Args2...>& u) { return true && (t.args < u.args) ...; } tuple<int,char> tu = { 0, 1 }; // You can also have tuple aggregates: template<typename ... Args> struct tuple_aggregate { Args ... args; }; tuple_aggregate<int,char,double> t = { 1, 2, 3 }; // conversions will take place And if the above equality and comparable operators were written using template template parameters - then we could compare tuple aggregates too. As regards concepts - they should not be impacted since we can not specify data member requirements. Anyway - Like you, I think there are compelling reasons to allow member template packs - and we should really try and put a DR or Proposal together asap. Even if it doesn't get accepted for C++09 - perhaps it can make it into the next TR. regards, Faisal Vali Radiation Oncology Loyola -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 1 Dec 2008 03:18 On 1 Dez., 00:29, Boris Rasin <rasin.bo...(a)gmail.com> wrote: > On Nov 30, 10:57 am, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> > wrote: > > > Maybe the introduction of variadic members opens up a can of worms ;-) > > Perhaps I am missing something obvious, but to me the following two > expansion cases seem extremely similar, even if not identical: > > template <typename ... Args> > struct store > { > store (Args ... args); // Case 1, allowed by current draft > Args ... members; // Case 2, NOT allowed by current draft > > }; > > In both cases compiler generates individual variables and in both > cases there is no syntax > to access them individually (your suggestion for array like individual > access syntax > would have to be applied in both cases and is a separate issue). > > What are the semantical or implementation differences which led to > acceptance > of case 1 into the draft but not the case 2? The key difference is that in (1) there are no variadic names with linkage (as of 3.5 [basic.link]) that could be named out of the scope of the varidic member function declaration. This is so, because function parameters and other variables of local scope cannot be named outside their scope. But in (2) the variadic member pack "members" would have linkage. It's easy to see that in Larry Evans' example where we have to find a way to "name" individual members. Now consider that we would (arbitrarily) decide that the member names would be chosen to be member1, member2, etc. This would cause a naming conflict in examples like these: template <typename ... Args> struct store { int members1; Args ... members; }; This problem would only occur if the pack has at least a size of 1 and the error is far from easy to understand. Therefore my suggestion to forbid explicit access to individual names of such a pack (The array-like notation would be one way to realize that). My - not yet confirmed - assumption is that implementors could solve the linkage name problem (that is the way how they uniquely assign their internal linkage names) for these entities, but we still need to invent new syntax to allow programmers to 'name' the pack members once they have instantiated such an entity as explained above. The same naming problem occurs in the double_all example that I provided (but that is not a different one from your proposed variadic members. If the first one is solved, the second one is easily provided). Greetings from Bremen, Daniel Kr�gler -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Faisal Vali on 1 Dec 2008 22:16
On Dec 1, 2:18 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> wrote: > On 1 Dez., 00:29, Boris Rasin <rasin.bo...(a)gmail.com> wrote: <snip> > > template <typename ... Args> > > struct store > > { > > store (Args ... args); // Case 1, allowed by current draft > > Args ... members; // Case 2, NOT allowed by current draft > > > }; > <snip> > The key difference is that in (1) there are no variadic names with > linkage (as of 3.5 [basic.link]) that could be named out of the scope > of the varidic member function declaration. This is so, because > function parameters and other variables of local scope cannot be > named outside their scope. > > But in (2) the variadic member pack "members" would have linkage. > It's easy to see that in Larry Evans' example where we have to find > a way to "name" individual members. Now consider that we would > (arbitrarily) decide that the member names would be chosen to be > member1, member2, etc. This would cause a naming conflict in > examples like these: I am not sure we need to have 'nameable' names for each member of the member template pack, to reap most of the benefits. I could live with: auto v1 = get<1>(store.members...); auto& v2 = get_ref<2>(store.members...); just as I can live with: get_type<1, Args...>::type > > template <typename ... Args> > struct store > { > int members1; > Args ... members; > > }; > > This problem would only occur if the pack has at least a size > of 1 and the error is far from easy to understand. Therefore > my suggestion to forbid explicit access to individual names > of such a pack (The array-like notation would be one way > to realize that). I like the array-like notation - but i'm not convinced that its impact would be minimal. > > My - not yet confirmed - assumption is that implementors > could solve the linkage name problem (that is the way how they > uniquely assign their internal linkage names) for these entities, > but we still need to invent new syntax to allow programmers to > 'name' the pack members once they have instantiated such an > entity as explained above. I am not sure we need to invent new syntax to get *most* of the benefits from member template packs. regards, Faisal Vali Radiation Oncology Loyola -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |