From: Tyson Whitehead <twhitehe@uwo.ca>
To: gcc@gcc.gnu.org
Subject: Template Template Matching Problem on Defaults (old g++ extension induced problem -- bug 9737)
Date: Mon, 20 Sep 2004 07:14:00 -0000 [thread overview]
Message-ID: <200409200040.03005.twhitehe@uwo.ca> (raw)
-----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-----
next reply other threads:[~2004-09-20 4:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-20 7:14 Tyson Whitehead [this message]
2004-09-20 17:47 Wolfgang Bangerth
2004-09-20 18:22 ` Gabriel Dos Reis
2004-09-20 19:04 ` Tyson Whitehead
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200409200040.03005.twhitehe@uwo.ca \
--to=twhitehe@uwo.ca \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).