Matthew Woehlke wrote:
$ gcc --version
gcc (GCC) 4.1.2
I have a program that looks roughly like this:
class Bar {
Bar(int);
Bar(char*);
// details aren't important
}
foo(Bar b) {
// ...
}
foo(bool a) {
foo (a ? 0 : Bar("hello"));
}
Basically, two overloads where one takes a bool and calls the other,
which has an identical signature except s/bool/Bar/, where one can pass
'0' for a Bar. As a result, the call when a==true is ambiguous... but
g++ -Wall doesn't warn about this. I was also a bit surprised that gcc
is generating code that calls a different function depending on the ?:
expression (maybe I shouldn't be), but it seems unlikely that this sort
of thing would be done intentionally very often.
So... is there a warning for this? Can/should there be?
John pointed out off-list that both parts of '?:' should be required to
evaluate to the same type, i.e. the above cannot generate calls to
different functions. This made me realize that my example is not so
good. Looking at the real code (see previous message), what I am
actually doing is 'foo( a ? 0 : EnumValue );', where there is an
implicit ctor Bar(Enum). Obviously, QFlags<T> is a bit of a special case
where the cast to QFlags<T> (i.e. "Bar") is always preferred over the
cast Enum->int->bool, but I'm not sure I can consider that a bug.
So... I guess I'd still like to see a warning. Conceptually, it's still
a "ambiguous call to foo()" warning, but emitted because g++ chose the
cast Enum->int->bool over the implicit Bar(int)+Bar(Enum) ctor casts.
But I have no idea how easy/hard that is to code :-(.
--
Matthew
The prhase "less is more" takes on a whole new meaning if you think
about standard Unix tools.
