This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Variadic templates, fourth revision (1/2)
- From: Jason Merrill <jason at redhat dot com>
- To: Doug Gregor <doug dot gregor at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 24 Jan 2007 17:35:10 -0500
- Subject: Re: Variadic templates, fourth revision (1/2)
- References: <24b520d20612080737n53c4a191w90bb75c119f54730@mail.gmail.com> <4581E1DD.9050608@redhat.com> <24b520d20612190628n3ff16f64p7830aebf656d381a@mail.gmail.com>
Sorry about the delay. This version looks quite good, just a few things
I'd like to clear up:
In dump_parameters, pre-existing code clears "first", and then you check
and clear it in the argument pack loop; I don't see any way it can be
other than 0 going into that loop.
In cp_walk_subtrees, I'd combine the expansion cases and use
PACK_EXPANSION_PATTERN.
The comment for FUNCTION_PARAMETER_PACK_P should mention PARM_DECL.
I'd like to use template_parameter_pack_p more places rather than open
code the DECL_INITIAL or TREE_TYPE: in pp_cxx_direct_declarator,
push_template_decl_real, and for setting parm_is_parameter_pack in
coerce_template_parms.
As an aside, the standardese added to [class.base.init] could use an
example; I had to look at the testsuite patch to see what a
mem-initializer expansion is supposed to look like.
I notice that for a mem-initializer expansion we make a type expansion
for the bases to be initialized, but leave the initializer as a plain
expression (possibly involving parameter packs); please add a comment
about why you don't make an expansion for the initializer as well. The
comment in finish_mem_initializers that handles the other end seems not
quite right; we skip checking the TREE_VALUE in that case because it's
part of the expansion even though that isn't represented in the tree
structure.
Please replace "unpacking" with "expansion" everywhere.
The ARGUMENT_PACK_SELECT stuff looks good.