Topic: Must variadic template parameters occur at the end of the template parameter list?


Author: Scott Meyers <NeverRead@aristeia.com>
Date: Thu, 17 Dec 2009 18:42:05 CST
Raw View
Is this valid in draft C++0x?

 template<typename ... Types1, typename ... Types2>
 class Foo;

gcc 4.4.1 both says no and says why:

 vartemp.cpp:33: error: parameter pack 'Types1' must be at the end of the
template parameter list

I can't find wording to back up this restriction, and in fact I find the
following in 20.5.2.7 of N3000:

 template<class... TTypes, class... UTypes>
 bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);

Is this a bug in gcc or a part of the draft standard that requires
amendment? If it's a gcc bug, am I correct in assuming that a
straightforward way to process variadic template parameters back-to-front
is:

 template<typename ... Ts> struct Foo;

 template<typename ... FirstTypes, typename LastType>
 struct Foo<FirstTypes..., LastType> {
   // do something with LastType, then recur to handle
   // the types in FirstTypes
 };

Thanks,

Scott

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Fri, 18 Dec 2009 15:01:42 CST
Raw View
On 18 Dec, 03:42, Scott Meyers <NeverR...@aristeia.com> wrote:
> Is this valid in draft C++0x?
>
>  template<typename ... Types1, typename ... Types2>
>  class Foo;
>
> gcc 4.4.1 both says no and says why:
>
>  vartemp.cpp:33: error: parameter pack 'Types1' must be at the end of the
> template parameter list
>
> I can't find wording to back up this restriction, and in fact I find the
> following in 20.5.2.7 of N3000:
>
>  template<class... TTypes, class... UTypes>
>  bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
>
> Is this a bug in gcc or a part of the draft standard that requires
> amendment? If it's a gcc bug, am I correct in assuming that a
> straightforward way to process variadic template parameters back-to-front
> is:
>
>  template<typename ... Ts> struct Foo;
>
>  template<typename ... FirstTypes, typename LastType>
>  struct Foo<FirstTypes..., LastType> {
>    // do something with LastType, then recur to handle
>    // the types in FirstTypes
>  };

See N3000 - 14.2/11: "If a template-parameter of a class template is a
template parameter pack, it shall be the last template-parameter.
[ Note: These are not requirements for function templates because
template arguments might be deduced (14.9.2)."


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: Larry Evans <cppljevans@gmail.com>
Date: Fri, 18 Dec 2009 15:02:43 CST
Raw View
On Dec 17, 6:42 pm, Scott Meyers <NeverR...@aristeia.com> wrote:
> Is this valid in draft C++0x?
>
>  template<typename ... Types1, typename ... Types2>
>  class Foo;
>
> gcc 4.4.1 both says no and says why:
>
>  vartemp.cpp:33: error: parameter pack 'Types1' must be at the end of the
> template parameter list
>
> I can't find wording to back up this restriction, and in fact I find the
> following in 20.5.2.7 of N3000:
>
>  template<class... TTypes, class... UTypes>
>  bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
>
> Is this a bug in gcc or a part of the draft standard that requires
> amendment? If it's a gcc bug, am I correct in assuming that a
> straightforward way to process variadic template parameters back-to-front
> is:
>
>  template<typename ... Ts> struct Foo;
>
>  template<typename ... FirstTypes, typename LastType>
>  struct Foo<FirstTypes..., LastType> {
>    // do something with LastType, then recur to handle
>    // the types in FirstTypes
>  };
>
> Thanks,
>
> Scott

Hi Scott.

One explanation for why packs are restricted to the end
is found here:

http://groups.google.com/group/comp.lang.c++.moderated/msg/e3c48abcdda846f0?hl=en

That's unfortunate because I would find them useful :(

HTH.

-Larry


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: SG <s.gesemann@gmail.com>
Date: Sat, 19 Dec 2009 09:16:47 CST
Raw View
On 18 Dez., 22:01, Nikolay Ivchenkov <ts...@mail.ru> wrote:
> On 18 Dec, 03:42, Scott Meyers <NeverR...@aristeia.com> wrote:
> > [...]
> >  template<typename ... Ts> struct Foo;
>
> >  template<typename ... FirstTypes, typename LastType>
> >  struct Foo<FirstTypes..., LastType> {
> >    // do something with LastType, then recur to handle
> >    // the types in FirstTypes
> >  };
>
> See N3000 - 14.2/11: "If a template-parameter of a class template is a
> template parameter pack, it shall be the last template-parameter.
> [ Note: These are not requirements for function templates because
> template arguments might be deduced (14.9.2)."

I think Scott brings up a valid point. I understand that multiple
parameter packs are not allowed for declaring a class template because
the user *has* to specify the arguments. The draft clearly allows
multiple parameter packs for function templates because template
parameters can be deduced. But the same is true for specializations.
The template parameters for a specialization are also deduced and
*never* supplied explicitly by the user.

So, I agree with Scott. I don't see a single reason why this
restriction should apply to class template *specializations* as well.
Either this is a serious and unfounded limitation of the draft or
GCC's implementation is just buggy. I think it's the latter because it
doesn't look like the section of the draft you quoted applies to class
template specializations.

Cheers,
SG


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: Olivier <olivier.grant@gmail.com>
Date: Sat, 19 Dec 2009 21:38:12 CST
Raw View
Hi,

i actually brought up this point a few months ago argumenting the same
point as Scott:

http://groups.google.com/group/comp.std.c++/browse_thread/thread/1576cf21b63c4d99/baaf0653c192ff36#baaf0653c192ff36

this would be a great feature added to variadic templates and Douglas
Gregor, at the time, seem to be saying that it could be introduced as
a defect fix.

I really hope it makes it in C++0x

Olivier Grant


> Either this is a serious and unfounded limitation of the draft or
> GCC's implementation is just buggy. I think it's the latter because it
> doesn't look like the section of the draft you quoted applies to class
> template specializations.
>
> Cheers,
> SG
>
> --
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@netlab.cs.rpi.edu]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]