I have tested the code below on Symantec C++ 6.0.1 for Macintosh and on
g++ 2.5.8 on SunOS, and both compilers violate the ARM requirements.  I
would like to know how other compilers handle this particular situation,
since I believe in this instance it is the standard that is wrong and
these two compilers that are closer to the mark.

//----------------
#include <iostream.h>

void foo(short s) { cout << "short " << s << endl; }
void foo(int n)   { cout << "int   " << n << endl; }

void bar(short s)        { cout << "short " << s  << endl; }
void bar(long double ld) { cout << "l-dbl " << ld << endl; }

void rab(long li) { cout << "long  " << li << endl; }
void rab(float f) { cout << "float " << f  << endl; }

main()
{
        char c = 22;
        foo(c); // Symantec flags ambiguous, g++ calls foo(short)
                // ARM 13.2 requires foo(int)

        double d = 26.7;
        bar(d); // both Symantec and g++ call bar(long double)
                // ARM 13.2 requires "ambiguous"

        char a = 28;
        int n = 29;
        rab(a); // both Symantec and g++ call rab(long) in both cases
        rab(n); // ARM 13.2 requires "ambiguous" in both cases.
        return 1;
}
//-------------

Function overloading is a very useful and powerful feature of C++, but
there is clearly still considerable confusion regarding the rules.  I
feel quite strongly that the behaviors marked above as required by the
ARM are highly undesirable, and no one has yet presented a credible
counterargument for the current system.  Clearly, more work is needed on
refining the rules for resolving overloaded function names.

If you disagree with my assessment, please say so and state your
reasoning; I find the silence which has followed my other posts quite
puzzling -- I've looked in the FAQ and I checked the FTP site for
updates on the ARM, and I haven't found any discussion of this issue.
Is there work currently underway on expanding the rules in ARM 13.2?

I have to date received one e-mail reply indicating that a
pre-production C++ compiler on UnixWare 2.0 SDK is ARM-13.2-compliant on
the examples shown above.  I would like to know about CFRONT, Borland,
Visual C++, and other major C++ compilers.

-- Linc Madison   *   Oakland, California   *   LincMad@Netcom.com

In article <lincmadCo34Ko.Cp2@netcom.com> lincmad@netcom.com (Linc Madison) writes:

   //----------------
   #include <iostream.h>

   void foo(short s) { cout << "short " << s << endl; }
   void foo(int n)   { cout << "int   " << n << endl; }

   void bar(short s)        { cout << "short " << s  << endl; }
   void bar(long double ld) { cout << "l-dbl " << ld << endl; }

   void rab(long li) { cout << "long  " << li << endl; }
   void rab(float f) { cout << "float " << f  << endl; }

   main()
   {
    char c = 22;
    foo(c); // Symantec flags ambiguous, g++ calls foo(short)
     // ARM 13.2 requires foo(int)

    double d = 26.7;
    bar(d); // both Symantec and g++ call bar(long double)
     // ARM 13.2 requires "ambiguous"

    char a = 28;
    int n = 29;
    rab(a); // both Symantec and g++ call rab(long) in both cases
    rab(n); // ARM 13.2 requires "ambiguous" in both cases.
    return 1;
   }
   //-------------

SunPro 4.0 says:

"foo.cc", line 20: Error: Overloading ambiguity between bar(short) and bar(long double).
"foo.cc", line 25: Error: Overloading ambiguity between rab(long) and rab(float).
"foo.cc", line 26: Error: Overloading ambiguity between rab(long) and rab(float).
3 Error(s) detected.

So it implements the ARM requirements. Can't test which function gets
called, since the program doesn't compile :-)

--JYL