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.

PengYu.UT@gmail.com wrote:

> 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.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

Phlip wrote:
> PengYu.UT@gmail.com wrote:
>
> > 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?

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?

>
> 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.
>
> --
>   Phlip
>   http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

PengYu.UT@gmail.com wrote:
> Phlip wrote:
> > PengYu.UT@gmail.com wrote:
> >
> > > 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?
>
> 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.

* Noah Roberts wrote, on 31/03/2006 22:53:
> PengYu.UT@gmail.com wrote:
>> 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. ;-)


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Noah Roberts wrote:

>> template <class T>
>> class Nil {
>> public:
>>   operator T* () { return static_cast<T*>(0); }
>
> 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. ;-)

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!! 

Phlip wrote:

> 
> Someone may have Template Fever here. ;-)
> 

Unfortunately, a far too common ailment.

-- 

Pete Becker
Roundhouse Consulting, Ltd.

PengYu.UT@gmail.com wrote:
> 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

Alf P. Steinbach wrote:
> * Noah Roberts wrote, on 31/03/2006 22:53:
> > PengYu.UT@gmail.com wrote:
> >> 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.

The OP wrote:

> > >>   operator T* () { return static_cast<T*>(0); }

Noah Roberts wrote:

> > > That cast is invalid

> Alf P. Steinbach wrote:

> > No.

Noah Roberts:

> > > What the original coder probably intended was a reinterpret cast.

Alf Steinbach:

> > No, that would be invalid. ;-)

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

Thomas Tutone wrote:

> 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.

Noah Roberts wrote:

> Thomas Tutone wrote:
>
> > 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).

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

Noah Roberts wrote:
> PengYu.UT@gmail.com wrote:
>>
>> template <class T>
>> class Nil {
>> public:
>>   operator T* () { return static_cast<T*>(0); }
>
> 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.

AARRRRRRRGHHHHH!

Old Wolf wrote:

> 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.

Diego Martins wrote:
> AARRRRRRRGHHHHH!

No shit, what a bunch of wankers.

Diego Martins wrote:

> 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.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!! 

Phlip wrote:
> Diego Martins wrote:
>
> > 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.

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

Diego Martins wrote:
> Phlip wrote:
> > Diego Martins wrote:
> >
> > > 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.
>
> 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.

Phlip wrote:

> Diego Martins wrote:
> 
> > 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.

The method in my .sig is one step shorter.



Brian
-- 
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.