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 29 Nov 2008 02:31 On Nov 28, 6:51 am, Larry Evans <cppljev...(a)suddenlink.net> wrote: > On 11/26/08 14:47, Daniel Kr�gler wrote: > [snip] > > > Just to be sure: have you sent this contributions also to > > comp.lang.c++.mod? I think your reply is quite important! > > Yes; however, I've not received any acknowledgment. > I think my newsreader (part of thunderbird) is still > giving me problems. Maybe you could just forward > this reply to the newsgroup to workaround my > newreader problems. However, I have cc'ed the > moderators directly, and if past experience is a > guide, this should work. > > BTW, one advantage of > > Args... members; > > is that it could avoid the extra overhead of the recursive > tuple implementation found on page 4 of: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2080.pdf > > That extra overhead was mentioned in post: > > http://lists.boost.org/Archives/boost/2002/01/23881.php > > -regards, > Larry Is it too late in the standardization process for this change? If not, how can we try to push for it? Boris. -- [ 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 29 Nov 2008 15:57 On 28 Nov., 05:51, Larry Evans <cppljev...(a)suddenlink.net> wrote: > On 11/26/08 14:47, Daniel Kr�gler wrote: > [snip] > > > Just to be sure: have you sent this contributions also to > > comp.lang.c++.mod? I think your reply is quite important! OK, it seems that the readers of this group should now be informed what Larry's contribution was ;-) He replied to the following part of my posting: > [..] And I would exclude argument (b) by simply > trying to fit this into the list of [temp.variadic]/4 > with the meaning of an ordered list of member > declarations such that > > Args... members; > > would have the meaning of > > Arg[0] member0; > Arg[1] member1; > ... as follows: <quote> Are you saying the compiler would actually generate the store member names, member0, member1, ..., membern? IOW the following code snippet: store<int,std::string,char> isc; int i = isc.member0; std::string s = isc.member1; char c = isc.member2; would compile? </quote> Here is my reply to this point (slightly modified for this group): <quote> You mention an important point and I agree that I didn't consider that one. My current position is - but that should be checked by compiler-writers - that I assume, that there does not really exist a linkage problem because of invented names. We already have unnamed namespaces which must be handled and I guess that internal names like member$1, member$2, ... could be assigned. Don't understand me wrong: These names should not be official (standardized), I just want to outline an implementation directive. My personal suggestion is, that users should not directly have a name to individuals parts of this variadic member pack. An interesting approach would be to support array-like access to selected parts of this sequence (pack) of members, like store<int,std::string,char> isc; int i = isc.member[0]; std::string s = isc.member[1]; char c = isc.member[2]; which is just the syntactic analogy to std::get for tuples. We probably need to ensure better disambiguation to normal array access (or operator[]). This could be done similarly to the new sizeof... operator: store<int,std::string,char> isc; int i = isc.member...[0]; std::string s = isc.member...[1]; char c = isc.member...[2]; I could also think of a library-solution that would simply work like this: store<int,std::string,char> isc; int i = get<0>(isc.member); std::string s = get<1>(isc.member); char c = get<2>(isc.member); This would indeed mean, that we have to extend unpacking rules, because currently the language does not allow this pack expansion in non-template code. </quote> > BTW, one advantage of > > Args... members; > > is that it could avoid the extra overhead of the recursive > tuple implementation found on page 4 of: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2080.pdf > > That extra overhead was mentioned in post: > > http://lists.boost.org/Archives/boost/2002/01/23881.php <nod>, this property is also a well-known reason to take advantage of the empty base class optimization (which is not the case of the above posting). You will find a nice discussion here: http://www.cantrip.org/emptyopt.html [ Another source of this article is: http://www.ddj.com/cpp/184410250 ] I see no convincing arguments regarding usage of variadic members versus variadic base classes, therefore I wouldn't take this as a reason for advocating to support them. My main reason for asking for them is that they a) would make the language more intuitive to use (provided, we solve the syntactic and any possibly open implementation issues) b) provide an easier to use mechanism to pack and unpack variadic structures. Maybe the introduction of variadic members opens up a can of worms ;-) It's easy to extend this kind of wish for non-type template variadics like in the following example: template<int... N> struct double_all { static const int... value = 2 * N...; // ? }; - Daniel -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: cppljevans on 29 Nov 2008 15:56 On Nov 27, 10:51 pm, Larry Evans <cppljev...(a)suddenlink.net> wrote: > On 11/26/08 14:47, Daniel Kr�gler wrote: > [snip] I should have included some context of my private post to Daniel: |>On 11/21/08 07:20, Daniel Kr�gler wrote: |>> On 20 Nov., 22:45, Boris Rasin <rasin.bo...(a)gmail.com> wrote: |>[snip] |>> variadic pack. And I would exclude argument (b) by simply |>> trying to fit this into the list of [temp.variadic]/4 with the |>> meaning |>> of an ordered list of member declarations such that |>> |>> Args... members; |>> |>> would have the meaning of |>> |>> Arg[0] member0; |>> Arg[1] member1; |>> ... |> |>Are you saying the compiler would actually generate the |>store member names, member0, member1, ..., membern? |>IOW the following code snippet: |> |> store<int,std::string,char> isc; |> int i = isc.member0; |> std::string s = isc.member1; |> char c = isc.member2; |> |>would compile? |> > > > Just to be sure: have you sent this contributions also to > > comp.lang.c++.mod? I think your reply is quite important! > > Yes; however, I've not received any acknowledgment. > I think my newsreader (part of thunderbird) is still > giving me problems. Maybe you could just forward > this reply to the newsgroup to workaround my > newreader problems. However, I have cc'ed the > moderators directly, and if past experience is a > guide, this should work. > > BTW, one advantage of > > Args... members; > > is that it could avoid the extra overhead of the recursive > tuple implementation found on page 4 of: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2080.pdf > > 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/thread/25b877b549f363c8# 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. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Boris Rasin on 30 Nov 2008 06:29 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? 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 30 Nov 2008 06:30
On Nov 30, 10:56 am, cppljev...(a)gmail.com wrote: > However, the following post: > > http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/ 25b877b549f363c8# > > 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. That post seems to describe non-conforming compiler. According to standard, for POD-structs, compiler can not pack next object into tail padding space, be it for base class or member variable. And for non-POD-struct, I guess compiler may do it, but then again, both for base class and member variable. Boris. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |