Thread: Is my C++ compiler broken?

Originally Posted by Elysia

I certainly agree that you should be unable to assign NULL to a non-pointer. Using an explicit cast to make it work is an evil workaround and I'm not sure such a thing should be allowed.

hand-holding? no thanks, if I wanted a compiler that assumes I'm stupid, I'll use javac.

To test out the last bit of your theory:

Code:

#include <cstdlib>
#include <cstring>
int main(){ memset(0, (int)(long)(int)NULL, 0);}

this compiles fine, so if it were overloading (int), it would have caught it there as well.

I guess I should take this up with the gnu/mingw mailing threads... I mean what possibly logical explanation could explain why

Code:

    memset(0, (int)(long)(int)NULL, 0); // this works
    memset(0, (int)NULL, 0); // and this does not

Why are you so obsessed with this? NULL is not meant to be an integer, and nullptr even less so.

> which expands to an implementation-defined null pointer constant;
Which basically means, use it in a non-pointer context (say the 2nd param of memset), and you code is broken.

You shouldn't care whether NULL is
0
(void*)0
nullptr

If you do, write better code. It's not like 0 is hard to write or anything.

Likewise, all the "works for me" casts of NULL which you've found to work also add nothing to the validity of your statements.

If it's all that important to you, though, here's the main GCC mailing list and here's the GCC bugzilla. You're welcome to bring your issue up with the people who actually write GCC. Don't be surprised if your bug is closed as WONTFIX, though.

A better bug to bring up would be "__nullptr should warn on conversion to any non-pointer type, not just int".

Originally Posted by Salem

If you do, write better code. It's not like 0 is hard to write or anything. Likewise, all the "works for me" casts of NULL which you've found to work also add nothing to the validity of your statements.

Some people still aren't getting the point: it's not about NULL, it's about the compiler behaving inconsistently across cases where its behaviour should be identical. See below.

Originally Posted by grumpy

I agree with this. @anthony, you seem to be arguing that since the conversion is supported for char and long, it should also be supported for int.

That right there is the point. The consistency is lacking, albeit in a very fringe case. In lieu of response from the mailing list, I think it's safe to say the compiler is broken in that regard.

Originally Posted by grumpy

The reason, as suggested by Elysia, is probably that a conversion to int has not been implemented, but a conversion to char or long has. It is possible to get the same effect fairly easily with standard C++ too.

Compiling your example code, I found that MSVC8 did indeed emit an error, as I thought would be the case. However, both the Comeau online compiler and the MinGW port of g++ 3.4.5 did not even emit a warning. Even after consulting the C++ Standard, I am not sure who is correct, but perhaps those two compilers treated it as an implicit conversion to char (or long), followed by an explicit conversion to int.

Originally Posted by @nthony

That right there is the point. The consistency is lacking, albeit in a very fringe case. In lieu of response from the mailing list, I think it's safe to say the compiler is broken in that regard.

Has a bug, maybe. Broken, no, since it is only an inconsistency in generating warnings.

EDIT:
Then again, it does seem that MSVC8's error message is correct since both the conversion to char and the conversion to long is equally viable (as I understand the rules), so there is ambiguity. The MinGW port of g++ 3.4.5 chooses to convert to char. I do not actually have the Comeau compiler, so I cannot observe what it does.

Originally Posted by @nthony

That right there is the point. The consistency is lacking, albeit in a very fringe case. In lieu of response from the mailing list, I think it's safe to say the compiler is broken in that regard.

Broken may be a bit lavish.

In any event: take CornedBee's suggestion: go to the gcc mail list or gcc bugzilla, and suggest "__nullptr should warn on conversion to any non-pointer type, not just int".

That will make the compiler behave in a consistent manner - and be helpful to programmers who make the type of silly mistake embodied in your "fringe case".

However, if your point is that consistency of the compiler is so important that the compiler should not report programmer errors that it can detect - which is what you seem to be suggesting - I consider you're barking up the wrong tree unless you can provide one practical example in which it is necessary to shut the compiler up in this case. By "practical example" I mean that there is a real-world problem that cannot be solved in any other way. A academic argument that "what the programmer says should go, even if the programmer is wrong" is insufficient.

Originally Posted by laserlight

Compiling your example code, I found that MSVC8 did indeed emit an error, as I thought would be the case. However, both the Comeau online compiler and the MinGW port of g++ 3.4.5 did not even emit a warning. Even after consulting the C++ Standard, I am not sure who is correct, but perhaps those two compilers treated it as an implicit conversion to char (or long), followed by an explicit conversion to int.

My guess would be that, for those compilers, long and int are the same types (I've yet to hear of a compiler where int and char were the same types, but suppose that is not beyond realms of possibility). Easy way to test that: add an operator int() - you will get one or more complaints from the compiler (either ambiguity, or something about duplicate operators). Alternatively, compare sizeof those types.

Generally, if I was seeking to implement conversion operators for a class X to all integral types, I would avoid conversions to signed or unsigned int (signed/unsigned int is typically equivalent to either its short or long counterpart) or to char (it is implementation-defined whether char is signed or unsigned char).

There is definitely no halfway recent compiler that won't be able to overload on int vs long, i.e. that treats them as canonically the same type internally.

My guess is that GCC and Comeau automatically prefer to conversion via char because it's guaranteed to have no data loss (under the assumption that the user-supplied operator doesn't cause data loss, which the compiler cannot know).

A check with the standard confirms this. The conversion char->int is an integral promotion, whereas long->int is a conversion. This makes Foo->char->int a better conversion than Foo->long->int, and overload resolution thus chooses the Foo->char operator.
See 13.3.3/1 (Best Viable Function) and 13.3.3.1.1 (Standard Conversion Sequences).

The fault lies with MSVC for not correctly implementing function overloading.

Would it matter if you're compiling 32-bit vs 64-bit? Since pointers would be 64-bit but and int might be 32-bit, so then the compiler would warn you that your target type isn't big enough...