From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5763 invoked by alias); 1 Nov 2003 09:15:46 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 5749 invoked by alias); 1 Nov 2003 09:15:45 -0000 Date: Sat, 01 Nov 2003 09:15:00 -0000 Message-ID: <20031101091545.5748.qmail@sources.redhat.com> From: "jhr dot walter at t-online dot de" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20031008065459.12536.jhr.walter@t-online.de> References: <20031008065459.12536.jhr.walter@t-online.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/12536] Regression regarding partial ordering X-Bugzilla-Reason: CC X-SW-Source: 2003-11/txt/msg00024.txt.bz2 List-Id: PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12536 ------- Additional Comments From jhr dot walter at t-online dot de 2003-11-01 09:15 ------- Subject: Re: Regression regarding partial ordering Dear Nathan, you wrote: > Actually, I beleive GCC is correct, but there is a DR about this somewhere. this > one, I think http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#214 > and #200 which points back to 214 Yes, I've noticed these defect reports (thanks to Chris Theis) and don't fully understand the relevance of their resolution for our problem. Are these resolutions already implemented in GCC? > Here is my reasoning. > 2. Overloaded bar() > > (i) template > some_type bar(A const& a, A const& = A()) > (ii) template > some_type bar(A const& a, R const& = R()) > > [14.5.5.2]/6 tells us that the presence of unused elliopsis and > default arguments have no effect on the partial ordering of > function templates. Just for the record: GCC 3.3.2 and ICC 7.1 correctly translate the example of [14.5.5.2]/6, GCC 2.95.3 is broken. > GCC takes that to mean that in > partial ordering we only consider the actual parameters explicitly > specified. Also partial ordering does not consider any explicitly > specified template arguments. > > what happens is that we can take (i) and deduce against (ii), ut > in deducing in the other direction we cannot deduce a type > for the first template parameter (R). so (ii) is more > specialized than (i). When I add template some_type baz(A const& a, A const&); template some_type bar(A const& a, R const&); to my example, all compilers agree to resolve baz(0, 0); to baz and I get the desired effect of controlling overload resolution (for some price). You've brought a strong argument that bar() should be handled like foo(). > #214 will allow the undeduce R, as is given an explicit arg, and is > not being used for partial ordering. Doing so will make deduction work > in both directions and hence make the ordering ambiguous. > > So all the compilers a wrong! Ouch. Thanks for your effort, Joerg