Re: zero and pointer conversions in g++

[Jack Lloyd <lloyd at randombit dot net>]

I believe the problem is that false (and bool()) have value 0, which is also a
pointer value in C (and in C++). C++ is attempting to do the least surprising
conversion, and in this case getting that 'wrong'. That is why test1 works and
test2 does not. I haven't bothered to check with the standard but I am fairly
certain what you are seeing is the expected type conversion for this case.

You can design around this by moving the special-case handling of strings in
Config::read into special-case handling in Variant::operator<<; that also
prevents the current situation where

   config.read("a", std::string("a"));
   config.read("b", Variant(std::string("b")));

result in different outputs, something which seems very counterintuitive to
me. I've attached some code I threw together to test some of these ideas, which
may be worth taking a glance at.

BTW, questions of this nature should probably be directed to the gcc-help list
rather than the main development mailing list.

-Jack

On Mon, Dec 26, 2005 at 02:04:52PM -0600, Thomas Braxton wrote:

> 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

[attached code snipped]

Attachment: variants.cpp
Description: Text document