From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-83658-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10342 invoked by alias); 25 Jan 2004 18:13:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 10263 invoked by alias); 25 Jan 2004 18:13:44 -0000
Date: Sun, 25 Jan 2004 18:13:00 -0000
Message-ID: <20040125181344.10262.qmail@sources.redhat.com>
From: "giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
In-Reply-To: <20030217232600.9737.gccbugs@contacts.eelis.net>
References: <20030217232600.9737.gccbugs@contacts.eelis.net>
Reply-To: gcc-bugzilla@gcc.gnu.org
Subject: [Bug c++/9737] [DR150] Partial template specialisation selection failure involving template parameter defaults
X-Bugzilla-Reason: CC
X-SW-Source: 2004-01/txt/msg03207.txt.bz2
List-Id: <gcc-bugs.sourceware.org>


------- Additional Comments From giovannibajo at libero dot it  2004-01-25 18:13 -------
Subject: Re:  [DR150] Partial template specialisation selection failure involving template parameter defaults

> Giovanni, I'm trying to understand how Bug 13809 is
> related to this one.  This (Bug 9737) describes partial
> specializations while Bug 13809 describes a
> template member function resolution in which case (as far as I can
> tell) the standard is clear which template member function should
> resolve.  This (Bug 9737) describes a template type resolution issue
> which (IMHO) is significantly different. Are the resolution
>  mechanisms different between bugs 13809 and 9737 ?

1) As explained in Bug 9737, our current behaviour allows to say:
template <template <class> class TT> class A;
A<std::set> a;

Becuase the type system allows this kind of match. I would like to make this an
official GCC extension, that can be optionally disabled in pedantic mode (or,
viceversa, allowed with -fpermissive).

2) For Bug 13809, the overload call is ambigous because partial ordering cannot
tell which overload function is the most specialized. Bug 9373 is about
ambigous match of a partial specialization, which uses exactly the same partial
ordering algorithm. This means that the code that selects the partial
specialization used for the instantiation in 9373 and the code that tries to
resolve the overload among the template covnersion functions is exactly the
same. Notice that this mandated by [temp.class.spec.match]/1, bullet 2: "If
more than one matching specialization is found, the partial order rules
(14.5.4.2) are used to determine whether one of the specializations is more
specialized than the others."

3) Given #1 and #2, you understand that there is indeed an ambiguity for GCC in
your testcase in Bug 13809. In fact, both the 2-parameter and 3-parameter
conversion functions are equally valid. The third-parameter overload is the
"correct" one, but the two-parameter is allowed as-well because of our
"extension".

This is why your bug is a duplicate of this one.

> Also, in the case
> of Bug 13809, the compiler diagnostic messages are incorrect becuase
> it reports invalid alternatives as ambiguities (AFAICT).

I can't understand where you read that GCC's std::set uses 4 template
parameters. There are only 3 parameters mandated by the C++ standard, and the
implemantation we have in v3 does implement it as 3-parameter template
(libstdc++-v3/include/bits/stl_set.h). So I can't see how the 4-parameter
conversion function would have had to be a possible match.

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9737