Re: Variadic templates
On 28 Nov., 05:51, Larry Evans <cppljev...@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! ]