By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,406 Members | 982 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,406 IT Pros & Developers. It's quick & easy.

C++ casts on zero

P: n/a
Hello,
Is the following statements legal (0 is actualy
a pointer parameter that could be '0' and relevant
to the casts) ?
MyClass* p = reinterpret_cast<MyClass*>(0);
MyClass* p = static_cast<MyClass*>(0);
Thanks and best regards,
Wenjie
Jul 19 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
On 17 Aug 2003 01:54:20 -0700, go****@yahoo.com (Wenjie) wrote:
Is the following statements legal (0 is actualy
a pointer parameter that could be '0' and relevant
to the casts) ?
MyClass* p = reinterpret_cast<MyClass*>(0);
MyClass* p = static_cast<MyClass*>(0);


That's not the problem.

What is the problem?
Jul 19 '05 #2

P: n/a
Wenjie wrote:
Hello,
Is the following statements legal (0 is actualy
a pointer parameter that could be '0' and relevant
to the casts) ?
MyClass* p = reinterpret_cast<MyClass*>(0);
MyClass* p = static_cast<MyClass*>(0);

What do you want to do? If you want a so-called NULL pointer, then forget
the reinterpret_cast. Why? Because that one is implementation defined.
And a NULL pointers implementation is not necessarily a pointer having the
same implementation as an integer containing zero. About the second cast::
it is unecessary. The 0 itself will automagically convert to a NULL pointer
of the right type.

WW aka Attila
Jul 19 '05 #3

P: n/a
Wenjie wrote:
Hello,
Is the following statements legal
Yes, though the result of the first is implementation defined.
(0 is actualy a pointer parameter that could be '0' and relevant
to the casts) ?
I don't understand that.
MyClass* p = reinterpret_cast<MyClass*>(0);
If you wanted a null pointer, note that the above doesn't necessarily
lead to one. It _might_ lead to a pointer with all bits zero, and that
pointer _might_ be a null pointer, but that's not guaranteed.
MyClass* p = static_cast<MyClass*>(0);


This is the same as:

MyClass* p = 0;

which makes p a null pointer.

Jul 19 '05 #4

P: n/a
On Sun, 17 Aug 2003 12:26:02 +0200, Rolf Magnus <ra******@t-online.de> wrote:
MyClass* p = static_cast<MyClass*>(0);


This is the same as:

MyClass* p = 0;

which makes p a null pointer.


Are you saying that MyClass* p = 0 always assigns the correct NULL pointer
value to p, even though the NULL value may not be zero on your particular
platform?

Jul 19 '05 #5

P: n/a
Dave Rahardja wrote:
On Sun, 17 Aug 2003 12:26:02 +0200, Rolf Magnus
<ra******@t-online.de> wrote:
MyClass* p = static_cast<MyClass*>(0);


This is the same as:

MyClass* p = 0;

which makes p a null pointer.


Are you saying that MyClass* p = 0 always assigns the correct NULL
pointer value to p, even though the NULL value may not be zero on
your particular platform?


Yes. As long as we speak of the C++ language. The standard requires this
behavior.

WW
Jul 19 '05 #6

P: n/a
On Sun, 17 Aug 2003 10:24:28 -0500, Dave Rahardja <as*@me.com> wrote:
On Sun, 17 Aug 2003 12:26:02 +0200, Rolf Magnus <ra******@t-online.de> wrote:
MyClass* p = static_cast<MyClass*>(0);


This is the same as:

MyClass* p = 0;

which makes p a null pointer.


Are you saying that MyClass* p = 0 always assigns the correct NULL pointer
value to p, even though the NULL value may not be zero on your particular
platform?


That's what he's saying: it's a requirement that the C++ standard
places on NULL.

Search the standard for NULL.

Note that there's a difference between the specification "0" and
the resulting bitpattern, which may or may not be all zeros.

Jul 19 '05 #7

P: n/a
On Sun, 17 Aug 2003 15:54:59 GMT, al***@start.no (Alf P. Steinbach) wrote:
On Sun, 17 Aug 2003 10:24:28 -0500, Dave Rahardja <as*@me.com> wrote:
On Sun, 17 Aug 2003 12:26:02 +0200, Rolf Magnus <ra******@t-online.de> wrote:
MyClass* p = static_cast<MyClass*>(0);

This is the same as:

MyClass* p = 0;

which makes p a null pointer.


Are you saying that MyClass* p = 0 always assigns the correct NULL pointer
value to p, even though the NULL value may not be zero on your particular
platform?


That's what he's saying: it's a requirement that the C++ standard
places on NULL.

Search the standard for NULL.

Note that there's a difference between the specification "0" and
the resulting bitpattern, which may or may not be all zeros.


Wow, you learn something new every day. I've still not downloaded the standard
(pure tightwad behavior on my part), but I should do that one of these days.

How about comparisons...

MyClass* p = 0;

if (p == 0) {
// Always true?
}

Jul 19 '05 #8

P: n/a
On Sun, 17 Aug 2003 16:32:42 GMT, Dave Rahardja <as*@me.com> wrote:

MyClass* p = 0;

if (p == 0) {
// Always true?
}


Yes.

Jul 19 '05 #9

P: n/a
"White Wolf" <wo***@freemail.hu> wrote in message news:<bh**********@phys-news1.kolumbus.fi>...
Wenjie wrote:
Hello,
Is the following statements legal (0 is actualy
a pointer parameter that could be '0' and relevant
to the casts) ?
MyClass* p = reinterpret_cast<MyClass*>(0);
MyClass* p = static_cast<MyClass*>(0);

What do you want to do? If you want a so-called NULL pointer, then forget
the reinterpret_cast. Why? Because that one is implementation defined.
And a NULL pointers implementation is not necessarily a pointer having the
same implementation as an integer containing zero. About the second cast::
it is unecessary. The 0 itself will automagically convert to a NULL pointer
of the right type.

WW aka Attila


I have a function accepting MyClass*, while the calling function did
a cast (reinterpret_cast) on the data to MyClass*:
calling_func() {
GenericData * p = generate_it();
accept_my_class(reinterpret_cast<MyClass*>(p));
}

then in accept_my_class(), I would like to check the NULL pointer-ness
firstly.
Thanks for your kind explanations.
Wenjie
Jul 19 '05 #10

P: n/a
Wenjie wrote:

I have a function accepting MyClass*, while the calling function did
a cast (reinterpret_cast) on the data to MyClass*:
calling_func() {
You need a return type for this function. ALL functions (except
constructors, destructors, conversion operators, and maybe some other
special cases I'm forgetting) must have explicit return types.
GenericData * p = generate_it();
accept_my_class(reinterpret_cast<MyClass*>(p));
}

then in accept_my_class(), I would like to check the NULL pointer-ness
firstly.


reinterpret_cast is the Wrong Thing to do in that case. In fact, this
reeks of poor organization. What is the relationship between GenericData
and MyClass? If there is none, then you shouldn't be treating one as if
it is the other. If there is a relationship between the two, then it
should probably be modeled through inheritance, which should make any
cast unnecessary.

A cast is often an indication of a design error, and always a potential bug.

If you tell us what you really want to do, we can probably recommend a
cleaner way to do it.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #11

P: n/a
Kevin Goodsell <us*********************@neverbox.com> wrote in message news:<3f411ed2@shknews01>...
Wenjie wrote:

I have a function accepting MyClass*, while the calling function did
a cast (reinterpret_cast) on the data to MyClass*:
calling_func() {


You need a return type for this function. ALL functions (except
constructors, destructors, conversion operators, and maybe some other
special cases I'm forgetting) must have explicit return types.
GenericData * p = generate_it();
accept_my_class(reinterpret_cast<MyClass*>(p));
}

then in accept_my_class(), I would like to check the NULL pointer-ness
firstly.


reinterpret_cast is the Wrong Thing to do in that case. In fact, this
reeks of poor organization. What is the relationship between GenericData
and MyClass? If there is none, then you shouldn't be treating one as if
it is the other. If there is a relationship between the two, then it
should probably be modeled through inheritance, which should make any
cast unnecessary.

A cast is often an indication of a design error, and always a potential bug.

If you tell us what you really want to do, we can probably recommend a
cleaner way to do it.

-Kevin

Thank you C++ people! I am being very late on the thread.
The problem is perhaps discussed here several times: it is
about message routing and dispatching. Concretely, we
have the following structure:

------- --------
| App0 | | App1 |
--o---- ----o---
| |
--o-----------o---
| Communication |
------------------
The communiation is socket based and it only cares about
the so called generic message header, the message body
is casted to and from in App0, App1, .... For App0, App1
etc's entry point, there is a message dispathing entity.

To add a little complexity to the discussion, some of the
Apps (protocol layers) is/are implemented in C on different
HW architecture.

Currently our engineer who architect the development have
the following C++ message structure definition:

typedef struct {
GenericHeader* pHead;
AppxData data;
} GenericMesage;
And then the ugly casts when AppxData is needed in Appx...
Best regards,
Wenjie
Jul 19 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.