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: Boris Rasin on 1 Dec 2008 22:58 On Dec 1, 10:18 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> wrote: > 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). Compiler already generates internal implementation dependent names with external linkage (lambda classes, for example), why this should be any different? Individual access syntax would be nice, but it is not required. Some useful constructs don't need it at all (like my initial sample for later forwarding). And in cases where it is needed (like tuple) a library solution is possible: template <typename ... Args> struct store { Args ... members; template <int i> std::get_type<i, Args...>::type get() { return std::get<i> (members...); } }; With std::get_type and std::get() implemented in standard library. Boris. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Boris Rasin on 1 Dec 2008 22:58 On Dec 1, 9:08 pm, Faisal Vali <fais...(a)gmail.com> wrote: > 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) Sounds like a lot of work, why couldn't I just throw a genius idea into the air and have someone else take care of all the pesky little details? :-) Why don't we all co-author this proposal? Boris. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Faisal Vali on 2 Dec 2008 23:15 On Dec 2, 9:58 am, Boris Rasin <rasin.bo...(a)gmail.com> wrote: > On Dec 1, 9:08 pm, Faisal Vali <fais...(a)gmail.com> wrote: > > > > > 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) > > Sounds like a lot of work, why couldn't I just throw a genius idea > into the air and have someone else take care of all the pesky little > details? :-) > > Why don't we all co-author this proposal? > Ok - here's the standardese to get us started - and while we're refining this, we should probably start work on documenting the introduction, motivation and a non-standardese description of the solution. Chapter 8 ------------ Add 8.3/8 A declarator-id or abstract-declarator containing an ellipsis shall only be used in a parameter-declaration or a member-declaration. ------------ Change the beginning of 8.3.5/13 From: A declarator-id or abstract-declarator containing an ellipsis shall only be used in a parameter-declaration. Such a parameter-declaration is a parameter pack (14.5.3). To: In a parameter-declaration, a declarator-id or abstract-declarator containing an ellipsis is a parameter pack (14.5.3). ----------- Chapter 9 Insert the following after 9.2/14 In a member-declaration, a declarator-id containing an ellipsis shall only be used in declaring a non-static data member. Such a member-declaration is a parameter pack (14.5.3). When it is part of a member-declaration, the parameter pack is a member declaration pack (14.5.3). The type T of the declarator-id of the member declaration pack shall contain a template parameter pack; each template parameter pack in T is expanded by the member declaration pack. Each member declaration pack, in effect, declares data members in the order of the types specified in the template parameter pack. [Note: this makes the layout predictable and consistent]. The individual data members declared by a member declaration pack do not have names. [Note: this is similar to elements of function parameter packs.] [Note: since a member declaration pack is simply auto-expanded by the compiler into a sequence of member-declarations, by itself it does not affect the literalness, the trivialness or other semantics of the containing type (union or class)]. When an initializer is specified, it is applied the same to each member declared by the member declaration pack. [ Example: template<typename ... T> struct S { T ... default_init_members; T ... list_init_members{}; T* ... ptr_members = nullptr; T (*...fun_ptr_members)(T,T) = nullptr; S() : default_init_members()... { } S(T...t) : default_init_members(t)... { } }; struct X { }; S<int,char,X> s; f(s.list_init_members...); auto v = std::get<1>(s.list_init_members...); -end example ] -------------------- Chapter 5 Expressions: Add the ...opt in the following grammar: 5.18 expression: assignment-expression ...opt expression, assignment-expression ...opt ----------------------------- Chapter 14 Templates [temp] 14.3 Template arguments [temp.arg] 14.5.3: A member declaration pack is a non-static data member declaration that declares zero or more non-static data members. [Example: template<class ... Types> struct store { Types ... members; }; store<int,char,store<double>> s = { 1, '2', { 3.0 } }; auto c = std::get<1>(s.members...); auto d = std::get<0>(get<2>(s.members...).members...); -end example] ------------------------- Replace 14.5.3/3 with: 3. A parameter pack is either a template parameter pack or a function parameter pack or a member declaration pack. ------------------------------ Add the following to 14.5.3/4: -- In an expression(5.18) the pattern is an assignment-expression Add the following examples to 14.5.3/5 [Example: f(s.members); // error: parameter pack 's.members' is not expanded s.members = s2.members; // error: parameter pack s.members and s2.members is not expanded s.members = s2.members ...; // error: parameter pack s.members is not expanded (s.members = s2.members)...; // ok (std::cout << s.members << std::endl)...; // ok bool all_equal = true && (s.members == s2.members) ...; // ok: use '&&' as the syntactically appropriate separator bool unintended = (s.members == s2.members) ...; // ok: but will use ',' as the syntactically appropriate separator template<class ... Types> struct store { Types ... members; std::string to_string() { std::ostringstream os; int idx = 0; (os << "[" << idx++ << ":" << typeid(Types).name() << "] = " << members << ", ")...; return os.str(); } }; store<int,char,store<double>> s = { 1, '2', { 3.0 } }; // use aggregate initialization -end example] ------------------------------------------- We could set up a google document to work on this - or if anyone has other ideas to facilitate collaboration - 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: Faisal Vali on 8 Dec 2008 05:46
On Dec 3, 10:15 am, Faisal Vali <fais...(a)gmail.com> wrote: > > We could set up a google document to work on this - or if anyone has > other ideas to facilitate collaboration - > All of you - please check out - http://stdcpp.wikidot.com/variatic-template-member-pack And provide us with feedback so we can get this right :) I have split up the proposal into two separate ones: an expression pack expansion and a member declaration pack. If you would like to edit the document - get an account at wikidot and then email boris - so that he can email you an invitation to get the privileges to edit the page. Even if it doesn't make it into C++0x - we might be able to get 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! ] |