No it isn't. It is no different than any other constant. That being said I normally use 0 since it works just as well.NULL is evil.
No it isn't. It is no different than any other constant. That being said I normally use 0 since it works just as well.NULL is evil.
void* cannot be implicitly converted to other pointer types, hence that wouldn't work.
So it was a tradeoff: either void* -> T* or 0 -> T*. Obviously the committee chose the later.
Now they've fixed that.
Yes. It. Is.
It's not being a constant that makes it evil - it's the type. A null pointer is not 0. And using 0 to initialize pointers is just as evil and stupid.
Initializing pointers with 0 will be kept for backwards compatibility! Initializing them with nullptr is the new way to go.
So that is the way everyone should do in any new code they write.
Thanks for the pearls of wisdom. Perhaps you ought to speak to Microsoft about the exception we get at address 0x00000000 when a null pointer is used.Initializing pointers with 0 will be kept for backwards compatibility! Initializing them with nullptr is the new way to go.
So that is the way everyone should do in any new code they write.
Your insistence on nullptr which isn't even supported in most compilers is equally so.And using 0 to initialize pointers is just as evil and stupid.
That is semantics. 0x123 could just as well be a pointer as an integer.
Thus, 0 could be a pointer or an integer.
However, "0" by itself is an integer by the language standard. So you would need a 0 of a type that can be implicitly converted to any pointer. Preferably that is not convertible to an int, because pointer is not an int.
Two major compilers which covers a huge percentage of the market supports it. That's good enough for me.Your insistence on nullptr which isn't even supported in most compilers is equally so.
If your compiler does not support it, then that's fine. But if it does, then use it.
Who cares? They're demonstrably wrong about 0 -> T* being OK. Meanwhile void* -> T* seems to be not OK because the type system thinks it isn't. Mind you, we are converting a plain address to a type T*. The committee made a mistake. Maybe they should be allied with the forces of darkness. C++ is evil! Deprecate C++!
Any ideas of why they choose to implement it as 0 in C++?
Since I'm full of vinegar at the moment, it was probably to break all the C code that was using malloc so it wouldn't automatically compile cleanly. People were forced to do things the C++ way.
The C committee is evil because 0 being a null pointer constant was inherited from C!
The fact that C allows implicit conversions between void* -> T* is evil, which C++ removed and hence put a gear into the wheels inherited from C.
So now the standards committee is fixing what is a flaw in the original, evil C standard, and making it properly type safe.
Who cares? All C++ programmers do, because we care about type safety and less evil exceptions! Deprecate C if anything. It's what's causing all these problems for C++.
Because (void*)0 wouldn't compile.
It was to fix the type systems and make it type safe, which C isn't.
Obviously it was more important to have a properly safe type system in C++ than maintaining backwards compatibility.
Apparently not as evil as taking
#define NULL ((void*)0)
or similar and making it integral zero. C++ broke some type safety it could have inherited from C.
And what should they have defined it as? Some other special number? Some special type?
They kind of broke some of the type system, obviously, but the net result was a safer type system than C has. Oh sorry, C doesn't have a safe type system.
I would love to find some history on why they simply defined it as 0 instead of properly fixing it back then, but finding something on google seems impossible...
Look man, you said it yourself. For some reason, people decided void* to T* was wrong. It depends on why it is wrong. I don't know, and no one tells me why. Knowing what void* is, how it works, I can't think of a sensible situation where it doesn't make sense because void* is a pointer and we're doing pointer conversion. In a world where void* to T* is type safe, if NULL was simply inherited from C unchanged, NULL is just another pointer constant. It was an evil mistake apparently.
void* is an address. Whatever it actually points to shouldn't matter and it's no worse than other implicit conversions and appears to be better than the one NULL does now. When void* becomes T* whatever is at the address is assumed to be T.
C++ made NULL 0. I won't quote, but the C standard should say something to the effect of it being a implementation defined pointer constant.
That's C talk.
Since the compiler stores data as binary, it is all the more important to treat objects correctly, that is, the proper type. With the introduction of operators and constructors and destructors, your talk becomes dangerous.
Unless S is a base class of T, T* cannot be implicitly converted to S*, because that would break the safe type system. You would say you had a pointer to an object that really isn't of the type you say it is.
And since void* is an unknown type, such conversion are inherently dangerous.
But the whole point is (and that I have argued) is that implicit conversion from 0 -> T* is evil. They've only now corrected it. Why they didn't from the beginning, I don't know.
Not arguing. You make the same assumptions about *T and *S when you convert explicitly though, so I am not sure I understand. RTTI isn't the devil, and C++ supports it. Not sure why compilers can't put it to use when pointer conversions are needed. There's just no point to the decision that's been made for NULL in the past. With most C++ features you end up paying the price at compile time. Sometimes that is dumb.T* cannot be implicitly converted to S* because blah