public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/8640: [2003-01-22] template specialization bug #2 (gcc3.2)
@ 2003-03-16 14:56 Giovanni Bajo
0 siblings, 0 replies; 2+ messages in thread
From: Giovanni Bajo @ 2003-03-16 14:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/8640; it has been noted by GNATS.
From: "Giovanni Bajo" <giovannibajo@libero.it>
To: <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>,
<nbecker@fred.net>,
"Wolfgang Bangerth" <bangerth@ticam.utexas.edu>,
<nobody@gcc.gnu.org>,
<gcc-prs@gcc.gnu.org>
Cc:
Subject: Re: c++/8640: [2003-01-22] template specialization bug #2 (gcc3.2)
Date: Sun, 16 Mar 2003 15:46:53 +0100
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p
r=8640
Yes, I (sadly) agree. In non-legalese, the problem is that partial ordering
does not take into account template parameters which are explicitally
specialized at function call time. For the logs, there is also an open DR
about partial ordering
(http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#214) which shows a
very similar case. I hope that in the end the above snippet will be
non-ambigous, but for now it rightfully is.
Giovanni Bajo
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: c++/8640: [2003-01-22] template specialization bug #2 (gcc3.2)
@ 2003-03-16 12:45 lerdsuwa
0 siblings, 0 replies; 2+ messages in thread
From: lerdsuwa @ 2003-03-16 12:45 UTC (permalink / raw)
To: bangerth, gcc-bugs, gcc-prs, nbecker, nobody
Synopsis: [2003-01-22] template specialization bug #2 (gcc3.2)
State-Changed-From-To: analyzed->closed
State-Changed-By: lerdsuwa
State-Changed-When: Sun Mar 16 12:45:09 2003
State-Changed-Why:
Not a bug. It's the way partial ordering works.
To see how this works, consider a simpler example:
template<typename T> void foo (T t); // #1
template<typename U> void foo (X<U> x); // #2
To find out which one is more specialized, you substitute
function argument into another function parameter and
try to deduce template parameter.
First, take a 't' of type 'T' from foo #1 and substitute
into foo #2 'u' parameter of type 'X<U>' like this.
foo<U>(X<U> t); // #2, where t of is any type T
You find that 't' can be any type, not necessary an
instantiation of class template X. So deduction
of 'U' fails. Here #1 is not more specialized than #2.
On the other hand, take a 'u' of type 'X<U>' from foo #2
and put into foo #1:
foo<T>(T x); // #1, where x of is any type X<U>
You can duduce T = X<U> here. So the deduction succeeds.
And #2 is more specialized than #1.
Deciding which specialization to use is based on the above
algorithm (which is specified in the C++ standard). If
one deduction fails, and another passes, we pick the more
specialized one. However with your code:
template<int shift1, typename T> void foo (T x);
template<int shift2, typename T> void foo (X<U> x);
'shift1' and 'shift2' cannot be deduced by the above
method, none is more specialized than the other. And
both are considered during a function call.
If you don't like how it works, comp.std.c++ newsgroup
is the place to discuss about the behavior.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8640
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-03-16 14:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-16 14:56 c++/8640: [2003-01-22] template specialization bug #2 (gcc3.2) Giovanni Bajo
-- strict thread matches above, loose matches on Subject: below --
2003-03-16 12:45 lerdsuwa
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).