Fwd: zero and pointer conversions in g++

[Thomas Braxton]

I sent this to the gcc mailing list and it was pointed out that I should have 
sent it here, so I am forwarding it here in hopes that someone can shed some 
light on this. Is this a bug in g++ or is this behavior mandated by the 
standard? Why would the conversion from bool(0) -> NULL -> string() be better 
than Variant(bool)? It seems to me that the selection of which function to 
use for false should be the same as for true. This also happens with int, if 
the argument is not 0 it chooses the Variant function.

BTW, the code is separated for strings for a reason, this is stripped down 
code from KDE and strings are possibly translated, everything else isn't,
so strings must be treated differently.

----------  Forwarded Message  ----------

Subject: zero and pointer conversions in g++
Date: Monday 26 December 2005 14:04
From: Thomas Braxton <brax108@cox.net>
To: gcc@gcc.gnu.org

I have this test code that I think g++ is selecting the wrong function when
the second argument is a zero. If compiled with HAVE_ASCII_DEFAULT 1 it
selects read(const char*, const char*) instead of read(const char*, const
Variant&), for test2a/test3a. If compiled with HAVE_ASCII_DEFAULT 0
compilation fails  because test2a/test3a are ambiguous. Shouldn't all of the
tests select the Variant function, or am I missing something? Why do I have
to explicitly create a Variant when the argument is zero?

Tested w/ g++ 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk) and 4.0.1 (self compiled)

TIA,
Thomas

PS please CC as I'm not subscribed

-------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: readentry.cpp
Type: text/x-c++src
Size: 2286 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20051227/2d8caa29/attachment.bin>