When to use null and when to use static_cast<some_pointer_type>(0)?

[PengYu.UT]

I see some code use static_cast<some_pointer_type>(0) instead of NULL
to describe null pointer. I'm wondering what is the pros and cons of
each way. Is there any reason why we should one verses the other.

 

[Phlip]

I see some code use static_cast<some_pointer_type>(0) instead of NULL
to describe null pointer. I'm wondering what is the pros and cons of
each way. Is there any reason why we should one verses the other.

What code does it the complex way? Could you post a sample?

NULL is magic, and should generally always appear as the constant "NULL".
Maybe you saw code that upgraded from C, which used (void*)0.

NULL is magic because a constant 0, in C++, always freely converts to any
pointer type, just as typesafely as if you had put an elaborate cast on it.
Don't.

 

[PengYu.UT]

What code does it the complex way? Could you post a sample?

template <class T>
class Nil {
public:
operator T* () { return static_cast<T*>(0); }
};

template <class T>
void Delete(T*& x) {
delete x;
x = Nil<T>();
}

The above is the code fragment.

In general, NULL is preferred, right?

 

[Noah Roberts]

template <class T>
class Nil {
public:
operator T* () { return static_cast<T*>(0); }

That cast is invalid and, luckily, unnecissary.

You can't static_cast between unrelated types. An int and a T* are
totally unrelated. Luckily enough, 0 is magic in that it can be any
pointer as well as an integral. So, that is just calling a static cast
from T* to T*...if it wasn't the code would not compile.

What the original coder probably intended was a reinterpret cast.
However, since the static cast worked it shows that it is not necissary
to perform any casting at all.

 

[Alf P. Steinbach]

* Noah Roberts wrote, on 31/03/2006 22:53:

template <class T>
class Nil {
public:
operator T* () { return static_cast<T*>(0); }

That cast is invalid
No.


and, luckily, unnecissary.
Yes.


[snip]
What the original coder probably intended was a reinterpret cast.

No, that would be invalid. ;-)

 

[Phlip]

That cast is invalid and, luckily, unnecissary.

I want to know why the Nil class is there. If its only purpose is this line

delete x;
x = Nil<T>();

then it is an excessive and unnecessary way to write x = NULL.

Someone may have Template Fever here. ;-)

 

[Pete Becker]

Someone may have Template Fever here. ;-)

Unfortunately, a far too common ailment.

 

[Michiel.Salters]

I see some code use static_cast<some_pointer_type>(0) instead of NULL
to describe null pointer. I'm wondering what is the pros and cons of
each way. Is there any reason why we should one verses the other.

Consider:

MyStream& operator<<(MyStream&, int);
MyStream& operator<<(MyStream&, const char*);

MyStream m;
m << NULL;
m << static_cast<char*>(0);

HTH
Michiel Salters

 

[Noah Roberts]

* Noah Roberts wrote, on 31/03/2006 22:53:

template <class T>
class Nil {
public:
operator T* () { return static_cast<T*>(0); }

That cast is invalid
No.


and, luckily, unnecissary.
Yes.


[snip]
What the original coder probably intended was a reinterpret cast.

No, that would be invalid. ;-)

Interesting. How do you figure? Since 0 is an int (except when used
as a pointer, which such added behavior is what renders any cast moot)
I can't think of any static_cast that is valid. In fact g++ pukes when
you try to static_cast but allows the reinterpret_cast through just
fine.

int main()
{
int x = 0;
int *r = reinterpret_cast<int*>(x);
int *p = static_cast<int*>(x);

return 0;
}

g++ stat.cpp
stat.cpp: In function `int main()':
stat.cpp:5: error: invalid static_cast from type `int' to type `int*'


g++ seems to think it is an invalid cast. So do I.

 

[Thomas Tutone]

Alf P. Steinbach wrote:

Noah Roberts:

Alf Steinbach:

Noah Roberts:

Interesting. How do you figure? Since 0 is an int (except when used
as a pointer, which such added behavior is what renders any cast moot)

You're starting from a flawed premise - or rather, your exception
swallows the rule.

I can't think of any static_cast that is valid. In fact g++ pukes when
you try to static_cast but allows the reinterpret_cast through just
fine.

int main()
{
int x = 0;
int *r = reinterpret_cast<int*>(x);
int *p = static_cast<int*>(x);

return 0;
}

Yes, but the following compiles fine:

int main()
{
int *r = reinterpret_cast<int*>(0);
int *p = static_cast<int*>(0);
}

What started out this subthread was your assertion that
static_cast<T*>(0) is an invalid cast. Alf Steinbach said it was
valid. He's right. In response you said that static_cast<T*>(i) was
an invalid cast where i==0. That's true, but different from your
original assertion.

Best regards,

Tom

 

[Noah Roberts]

What started out this subthread was your assertion that
static_cast<T*>(0) is an invalid cast.

I made so such assertion (I'm being quoted out of context), in fact I
explained why it was (go back and read my first responce, I state
clearly that that cast is valid for the same reason it is unnecissary).


What I said was that if the cast was necissary it would be an invalid
one as it would be a cast from an int to a T* and that is not a valid
static cast - such a cast would have to be a reinterpret_cast.

 

[Thomas Tutone]

I made so such assertion (I'm being quoted out of context), in fact I
explained why it was (go back and read my first responce, I state
clearly that that cast is valid for the same reason it is unnecissary).

If you say so. I went back and read your first response. I don't see
where you say that the cast is valid, only where you say it is invalid.
But I don't want to argue semantics with you. You and I can agree
that it should not be necessary to cast 0 to assign it to a variable of
any pointer type.

What I said was that if the cast was necissary it would be an invalid
one as it would be a cast from an int to a T* and that is not a valid
static cast - such a cast would have to be a reinterpret_cast.

Best regards,

Tom

 

[Old Wolf]

That cast is invalid and, luckily, unnecissary.

Later in the thread you attempt to deny that you wrote
this statement....

The above cast is definitely valid.

You can't static_cast between unrelated types. An int and a T* are
totally unrelated.

You can static_cast in any situation where there is an implicit
conversion from source to destination.

Here's another example:

struct A { };
struct B { operator A() { return A(); } };

int main() { static_cast<A>(b); }

Classes A and B are unrelated but the static_cast is good.

Luckily enough, 0 is magic in that it can be any
pointer as well as an integral.

0 cannot be a pointer. 0 is an integer.

So, that is just calling a static cast from T* to T*

It is a static cast from the integer constant 0 to a pointer to T.

There is an implicit conversion defined from integral constants
of value 0 (also known as null-pointer constants), to pointers.

...if it wasn't the code would not compile.

Nonsense, the code is fine.

What the original coder probably intended was a reinterpret cast.

He certainly did not intend that, as a reinterpret cast would not
generate a null pointer in the case where null pointers are not
all-bits-zero. I hate to think what it would do in the case where
the pointer has more bits than an integer.

However, since the static cast worked it shows that it is not
necissary to perform any casting at all.

You just said that the code would not compile without the
static cast, now you say that the cast is not necessary.

 

[Diego Martins]

AARRRRRRRGHHHHH!

 

[Noah Roberts]

You just said that the code would not compile without the
static cast, now you say that the cast is not necessary.

Now you are just making things up.

Don't go away mad, just go away.

 

[Noah Roberts]

AARRRRRRRGHHHHH!

No shit, what a bunch of wankers.

 

[Phlip]

AARRRRRRRGHHHHH!

When you reply using Google Groups, please hit Reply -> Preview -> Edit, to
force Google to select the replied-to text. (They are optimizing their own
servers when they trick you into leaving out that text.

Then we will know who had this wonderful affect on you.

 

[Diego Martins]

When you reply using Google Groups, please hit Reply -> Preview -> Edit, to
force Google to select the replied-to text. (They are optimizing their own
servers when they trick you into leaving out that text.

Then we will know who had this wonderful affect on you.

heh! it was the whole thread! you are discussing the sex of the angels

 

[Noah Roberts]

heh! it was the whole thread! you are discussing the sex of the angels

Well, I guess it is possible that Michael is a mistranslation and
should be Michelle and I _have_ met women named Gabrielle...but I'm
still under the impression that they are masculine entities.

 

[Default User]

When you reply using Google Groups, please hit Reply -> Preview ->
Edit, to force Google to select the replied-to text. (They are
optimizing their own servers when they trick you into leaving out
that text.

The method in my .sig is one step shorter.



Brian