Re: Template Template Matching Problem on Defaults (old g++ extension induced problem -- bug 9737)

Re: Template Template Matching Problem on Defaults (old g++ extension induced problem -- bug 9737)

[Wolfgang Bangerth]

> Anyone have an update for September 2004?

I don't, but I just files PR 17570 for this. You may want to put yourself 
on the CC list.


> PS:  I also don't get what analogue this extension was suppose to 
> maintain with function function parameters (see bug report).  I just 
> finished checking, and g++ certainly does not allow things like 
> assigning an n (non default) plus m (default) argument function to an n 
> argument function pointer.

That isn't the point. The reason was so that people can match
  std::vector<int>
  std::set<int>
  ...
etc to template template parameters with only one template argument, 
despite the fact that these classes have more than just one, and possibly 
different numbers of template arguments, all of which except for the first 
have default arguments.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Template Template Matching Problem on Defaults (old g++ extension induced problem -- bug 9737)

[Gabriel Dos Reis]

Wolfgang Bangerth <bangerth@ices.utexas.edu> writes:

| > Anyone have an update for September 2004?
| 
| I don't, but I just files PR 17570 for this. You may want to put yourself 
| on the CC list.
| 
| 
| > PS:  I also don't get what analogue this extension was suppose to 
| > maintain with function function parameters (see bug report).  I just 
| > finished checking, and g++ certainly does not allow things like 
| > assigning an n (non default) plus m (default) argument function to an n 
| > argument function pointer.
| 
| That isn't the point. The reason was so that people can match
|   std::vector<int>
|   std::set<int>
|   ...
| etc to template template parameters with only one template argument, 
| despite the fact that these classes have more than just one, and possibly 
| different numbers of template arguments, all of which except for the first 
| have default arguments.

The Core group clarified the point saying that template parameters
and default arguments are intended to be treated the same way as
function parameters and default arguments.

With template aliases coming in, I think this extension can go away.

-- Gaby

Re: Template Template Matching Problem on Defaults (old g++ extension induced problem -- bug 9737)

[Tyson Whitehead]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On September 20, 2004 12:11 pm, Wolfgang Bangerth wrote:
> That isn't the point. The reason was so that people can match
>   std::vector<int>
>   std::set<int>
>   ...
> etc to template template parameters with only one template argument,
> despite the fact that these classes have more than just one, and possibly
> different numbers of template arguments, all of which except for the first
> have default arguments.

On September 20, 2004 12:52 pm, Gabriel Dos Reis wrote:
> The Core group clarified the point saying that template parameters
> and default arguments are intended to be treated the same way as
> function parameters and default arguments.
> 
> With template aliases coming in, I think this extension can go away.


Thanks all, for the clarification.

It probably moot for this case, as it sounds like this non-core extension will 
probably be going out with template alias coming in, but shouldn't g++ 
extensions that provide extra candidates over the C++ standard be made to 
match less strongly then C++ standard candidates to ensure g++ specific 
ambiguities aren't introduced into perfectly valid code (such as that in the 
original email)?

- -T

- -- 
 Tyson Whitehead  (-twhitehe at uwo.ca -- WSC-)
 Computer Engineer                        Dept. of Applied Mathematics,
 Graduate Student- Applied Mathematics    University of Western Ontario,
 GnuPG Key ID# 0x8A2AB5D8                 London, Ontario, Canada
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBTx/XRXbLmIoqtdgRAjM+AKDtkEIRgvQQ71GuELB2BC62I9gRZgCfeFOB
WqOklFtxnqAJjA1M/3ii+rs=
=uH3W
-----END PGP SIGNATURE-----

Template Template Matching Problem on Defaults (old g++ extension induced problem -- bug 9737)

[Tyson Whitehead]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At some point in time an extension was added to g++ in order to make a 
template template specialization for n parameters match a template with n+m 
parameters, when the extra m parameters have default values.  This cause the 
undesirable side effect of breaking the breaking the following (valid) code 
(I verified this with g++ 3.3-3.5):

- ---
template<typename> struct match { };
template<template<typename> class t_,typename T_> 
struct match<t_<T_> > { typedef int type; };
template<template<typename,typename> class t_,typename T0_,typename T1_>
struct match<t_<T0_,T1_> > { typedef int type; };

template<typename,typename _=void> struct other { };

typedef match<other<void,void> >::type type;

Bug.cpp:9: error: ambiguous class template instantiation for `struct 
match<other<void, void> >'
Bug.cpp:5: error: candidates are: struct match<t_<T0_, T1_> >
Bug.cpp:3: error:                 struct match<t_<T_> >
- ---

A patch to make the compiler compliant with regards to this issue was provided 
in April 2003.  The bug was suspended, with out the patching be 
applied/extension being removed, due to possible changes in the next C++ 
standard.

Anyone have an update for September 2004?  Is it not part of the standard 
(finger's crossed)?  Can we remove/depreciate this extension (as seemed to be 
the conclusion reached on the mailing list discussion around the submitted 
patch -- http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01410.html) so I can 
compile my code (or at least make the g++ specific matching extension bind 
less tightly than what C++ standard choice).

- -T

PS:  I also don't get what analogue this extension was suppose to maintain 
with function function parameters (see bug report).  I just finished 
checking, and g++ certainly does not allow things like assigning an n (non 
default) plus m (default) argument function to an n argument function 
pointer.

- -- 
 Tyson Whitehead  (-twhitehe@uwo.ca -- WSC-)
 Computer Engineer                          Dept. of Applied Mathematics,
 Graduate Student- Applied Mathematics      University of Western Ontario,
 GnuPG Key ID# 0x8A2AB5D8                   London, Ontario, Canada
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBTl8iRXbLmIoqtdgRAiRvAKDdkAdi9hdT6RJ6dBXJ4LNUVrWAhACdEQaY
RylQmYDmi9efOwOMazvIczs=
=nrGH
-----END PGP SIGNATURE-----