Re: c++/1617: partial ordering of function templates

[Martin Sebor <sebor@roguewave.com>]

The following reply was made to PR c++/1617; it has been noted by GNATS.

From: Martin Sebor <sebor@roguewave.com>
To: Nathan Sidwell <nathan@codesourcery.com>
Cc: Gabriel Dos Reis <gdr@codesourcery.com>, gcc-gnats@gcc.gnu.org
Subject: Re: c++/1617: partial ordering of function templates
Date: Fri, 12 Jan 2001 18:21:08 -0700

 Nathan Sidwell wrote:
 > 
 > Hi,
 > more partial ordering questions. I've got another corner case, which I'm
 > unsure
 > of which way to resolve.
 > Consider
 > template <typename T> int Bar (T const *const &);       #1
 > template <typename T> int Bar (T *const &);             #2
 > template <typename T> int Bar (T *);                    #3
 > 
 > int const *cp;
 > int *p;
 > 
 > Bar (cp);       #a
 > Bar (p);        #b
 > 
 > what should be called at #a and #b, or are either ambiguous. Here are
 > the deductions,
 > 
 > #a; #1->int, #2->const int, #3->const int
 > #b; #1->int, #2->int, #3->int
 > 
 > I think #1 should be more specilized than #2 and #2 should be more
 > specialized than #3. #1 should be more specialized than #3. I'm having
 > trouble getting that ordering to work for both #a and #b.
 
 Ouch, you're making my head hurt ;-)
 
 Despite what EDG thinks, I would probably agree that #1 is more specialized than
 #2 or #3, so #a should resolve to #1. I'm not so sure about the difference
 between #2 and #3, though. Taking #1 out of the set, I'd say the call #a should
 be ambiguous (EDG disagrees, picking #3 again).
 
 In the case of #b I'd probably consider #2 and #3 ambiguous. It would certainly
 be if the signatures did not involve pointers (ie., T const& and T,
 respectively).
 
          ARGUMENT        [DEDUCED TYPE]
 #a: cp : int const* <==> [T = int] const* const&    best viable   #1
                          [T = int const]* const&         viable   #2
                          [T = int const]*                viable   #3
                          
 #b: p  : int*       <==> [T = int] const* const&     not viable   #1
                          [T = int]* const&               viable   #2
                          [T = int]*                      viable   #3
                 
 
 > 
 > I'd be interested what other compilers do on the attached program
 > (modulo the __PRETTY_FUNCTION__ bit :-)
 
 Here are [some of] the mainstream compilers:
 
 +-------------+---+---+---+---++---+---++---+---+
 |call -->     | a | b | c | d || e | f || g | h |
 +=============+===+===+===+===++===+===++===+===+
 |EDG eccp 2.44| 1 | 1 | 3 | 2 || 6 | 6 || 7 | 7 |
 +-------------+---+---+---+---++---+---++---+---+
 |gcc 2.95.2   | E | E | 3 | 2 || E | E || 7 | 7 |
 +-------------+---+---+---+---++---+---++---+---+
 |HP aCC 3.26  | E | E | E | 2 || E | E || 7 | 7 |
 +-------------+---+---+---+---++---+---++---+---+
 |IBM xlC 5.0  | E | E | 3 | 2 || E | E || 7 | 7 |
 +-------------+---+---+---+---++---+---++---+---+
 |MSVC 6.0     | E | E | E | 2 || 6 | 6 || E | E |
 +-------------+---+---+---+---++---+---++---+---+
 |SunPro 5.2   | 2 | 2 | 3 | 2 || 5 | 5 || 7 | 7 |
 +-------------+---+---+---+---++---+---++---+---+
                 ^   ^  ...       ^   ^   ...
                 |   |            |   |
                 |   |            |   +-- your #b above
                 |   |            +------ your #a above
                 |   |
                 |   +- foo (ptr2)
                 +- foo (ptr)
 
 Martin
 
 
 $ for s in a b c d e f g h ; do printf "*** $%s: " $s ; $CC -D $s t.cpp
 >/dev/null 2>&1 ; if [ $? -eq 0 ] ; then ./a.out ; else echo "ERROR" ; fi ; done
 
 $ cat t.cpp
 
 extern "C" int puts (const char*);
 
 #define TEMPLATE(name, arg, n)   \
    template <class T> const char* name (arg) { return #name "(" #arg ") #" #n; }
 
 #if defined (a) || defined (b) || defined (c) || defined (d)
 TEMPLATE (foo, T*, 1)
 TEMPLATE (foo, T&, 2)
 TEMPLATE (foo, T const&, 3)
 #endif
 
 #if defined (e) || defined (f)
 TEMPLATE (bar, T const* const&, 4)
 TEMPLATE (bar, T* const&, 5)
 TEMPLATE (bar, T*, 6)
 #endif
 
 #if defined (g) || defined (h)
 TEMPLATE (quux, T* const&, 7)
 TEMPLATE (quux, T const&, 8)
 #endif
 
 void baz (int const *ptr, int *ptr2)
 {
 #ifdef a
     puts (foo (ptr));
 #endif
 #ifdef b
     puts (foo (ptr2));
 #endif
 #ifdef c
     puts (foo (*ptr));
 #endif
 #ifdef d
     puts (foo (*ptr2));
 #endif 
 
 #ifdef e
     puts (bar (ptr));
 #endif
 #ifdef f
     puts (bar (ptr2));
 #endif
 
 #ifdef g  
     puts (quux (ptr));
 #endif
 #ifdef h
     puts (quux (ptr2));
 #endif
 }
 
 int main ()
 {
     baz (0, 0);
 }
>From dobowman@cisco.com Sun Apr 01 00:00:00 2001
From: "Don Bowman" <dobowman@cisco.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: RE: c++/1571
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010107152601.28877.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00077.html
Content-length: 1168

The following reply was made to PR c++/1571; it has been noted by GNATS.

From: "Don Bowman" <dobowman@cisco.com>
To: <neil@gcc.gnu.org>, <cgd@sibyte.com>, <gcc-gnats@gcc.gnu.org>,
        <nobody@gcc.gnu.org>
Cc:  
Subject: RE: c++/1571
Date: Sun, 7 Jan 2001 10:23:48 -0500

 Perhaps the message could be changed?
 
 In my case its still a problem since its an
 embedded system, I've got wchar_t == char,
 not int, but now the compiler has the wrong
 width.
 
 Also, some people may not have access to the
 system header files to change them to put
 the cplusplus protection around that type.
 Perhaps a command-line option to disable this
 internal type?
 
 -----Original Message-----
 From: neil@gcc.gnu.org [ mailto:neil@gcc.gnu.org ]
 Sent: January 7, 2001 6:45 AM
 To: dobowman@cisco.com; cgd@sibyte.com; gcc-gnats@gcc.gnu.org;
 nobody@gcc.gnu.org
 Subject: Re: c++/1571
 
 
 Synopsis: g++ is confused with by code that typedef's wchar_t.
 
 State-Changed-From-To: open->closed
 State-Changed-By: neil
 State-Changed-When: Sun Jan  7 03:44:32 2001
 State-Changed-Why:
     User-error :-)
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1571&database=gcc
 
>From neil@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: neil@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c/1814
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010304002600.20064.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01984.html
Content-length: 552

The following reply was made to PR c/1814; it has been noted by GNATS.

From: neil@gcc.gnu.org
To: dakott@pobox.com, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c/1814
Date: 4 Mar 2001 00:25:48 -0000

 Synopsis: fr30-elf 2.97 cross-compiler segmentation faults on FreeBSD 4.2-stable building libgcc
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: neil
 State-Changed-When: Sat Mar  3 16:25:48 2001
 State-Changed-Why:
     No feedback forthcoming.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1814&database=gcc