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 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

* 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

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 12:45 c++/8640: [2003-01-22] template specialization bug #2 (gcc3.2) lerdsuwa
2003-03-16 14:56 Giovanni Bajo

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).