g++ 2.7.0: bool vs. string vs. const char* overloading
Per Abrahamsen
Can anyone explain to me why two doIt calls below select different
overloaded functions?
------------- bug.C -------------
#include <iostream.h>
#include <string>
void doIt (string)
{
cout << "Gotta string\n";
}
void doIt (bool)
{
cout << "Gotta bool\n";
}
int main ()
{
const char* const cp = "Hi!";
doIt (cp);
doIt ("Hi!");
return 0;
}
--------------------------------
daisy% c++ -Wall -g -v -o bug bug.C
gcc -Wall -g -v -o bug bug.C -lstdc++
Reading specs from /pack/gcc/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0/specs
gcc version 2.7.0
/pack/gcc/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=7 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -g -Wall bug.C /var/tmp/cca000ah.ii
GNU CPP version 2.7.0 (sparc)
#include "..." search starts here:
#include <...> search starts here:
/pack/gcc/lib/g++-include
/usr/local/include
/pack/gcc/sparc-sun-solaris2.4/include
/pack/gcc/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0/include
/usr/include
End of search list.
/pack/gcc/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0/cc1plus /var/tmp/cca000ah.ii -quiet -dumpbase bug.cc -g -Wall -version -o /var/tmp/cca000ah.s
GNU C++ version 2.7.0 (sparc) compiled by GNU C version 2.7.0.
/usr/ccs/bin/as -V -Qy -s -o /var/tmp/cca000ah1.o /var/tmp/cca000ah.s
/usr/ccs/bin/as: SC3.1 dev 09 May 1994
/usr/ccs/bin/ld -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o bug /pack/gcc/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0/crt1.o /pack/gcc/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0/crti.o /usr/ccs/lib/values-Xa.o /pack/gcc/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0/crtbegin.o -L/pack/gcc/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0 -L/usr/ccs/bin -L/usr/ccs/lib -L/pack/gcc/lib /var/tmp/cca000ah1.o -lstdc++ -lgcc -lc -lgcc /pack/gcc/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0/crtend.o /pack/gcc/lib/gcc-lib/sparc-sun-solaris2.4/2.7.0/crtn.o
ld: Software Generation Utilities (SGU) SunOS/ELF (LK-1.4 (S/I))
daisy% bug
Gotta bool
Gotta string
Compilation finished at Thu Nov 2 14:37:47
Alex Martelli
...
>Can anyone explain to me why two doIt calls below select different
>overloaded functions?
>void doIt (string)
...
>void doIt (bool)
...
> const char* const cp = "Hi!";
> doIt (cp);
> doIt ("Hi!");
There is no conversion from a const char* to a non-const string,
while there is one from any pointer to bool, so the first call
will surely end up calling doIt(bool). The literal "Hi!" is
a (non-const) char* (for historical reasons) -- I confess I'm
not sure why the user-defined conversion to string is
unambiguously preferred to the builtin one to bool (perhaps
the latter would have to go through a _const_ char*...?)
Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: mart...@cadlab.it Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia Fax: +39 (51) 597120
James Kanze US/ESC 60/3/141 #40763
abr...@dina.kvl.dk (Per Abrahamsen) writes:
|> Can anyone explain to me why two doIt calls below select different
|> overloaded functions?
Compiler bug?
|> ------------- bug.C -------------
|> #include <iostream.h>
|> #include <string>
|> void doIt (string)
|> {
|> cout << "Gotta string\n";
|> }
|> void doIt (bool)
|> {
|> cout << "Gotta bool\n";
|> }
|> int main ()
|> {
|> const char* const cp = "Hi!";
|> doIt (cp);
Should call do( bool ), since a pointer converts to a bool implicitly
(and the conversion, which doesn't use any user defined conversions,
has precedence over the conversion to string, which involves calling
the constructor).
|> doIt ("Hi!");
Same as above.
|> return 0;
|> }
Rigorously speaking, it is an error. On the other hand, I can easily
imagine a compiler having an extension which allows literal string
constants (like "Hi!") to be treated exactly as strings (even up to
correctly initializing static memory for a string statically).
--
James Kanze Tel.: (+33) 88 14 49 00 email: ka...@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
-- Beratung in industrieller Datenverarbeitung