 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
andrew_nuss@yahoo.com
Guest
|
 Posted: Wed Aug 30, 2006 8:02 pm Post subject: stroustrup, void*, and reinterpret_cast |
 |
|
Hi,
I've noticed that on pg. 342 of Stroustups "C++ Programming Language"
book his example of using partial specialization for a custom vector
template where T is a pointer to anything to avoid bloat, he uses
reinterpret_cast to go back and forth between void* and T* pointers.
Why? Why not use static_cast?
1) he made a mistake (unlikely)
2) does static_cast with complicated T* to void* cause address shifts?
If so this could cause problems with preservation of a NULL value as
well as a round-trip inconsistency. My feeling is that
reinterpret_cast simply will not change the actual pointer value stored
from the assembly perspective in either direction, which is desired.
3) is it because of ever so slightly better performance?
As a result of his example, I have decided throughout my program to use
reinterpret_cast to go back and forth between void* and typed pointers.
I use static_cast only when narrowing to a derived type from a base
class type.
Can anyone give me the decisive opinion on this issue with
reinterpret_cast and void*, and in particular, why Stroustup uses
reinterpret_cast instead of static_cast?
Thanks,
Andy
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Frederick Gotham
Guest
|
| Posted: Thu Aug 31, 2006 8:02 pm Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
andrew_nuss (AT) yahoo (DOT) com posted:
| Quote: | As a result of his example, I have decided throughout my program to use
reinterpret_cast to go back and forth between void* and typed pointers.
|
Why adopt someone else's style before you even understand why? It is not a
good way to learn.
If you want to convert a void* to any other pointer type, use static_cast:
void *pv = 0;
int *pi = static_cast<int*>(pv);
I don't have Bjarne's book here with me, so I can't look over the code
snippet. Perhaps he used reinterpret_cast simply because it slipped his mind
that static_cast would get the job done.
--
Frederick Gotham
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
andrew_nuss@yahoo.com
Guest
|
| Posted: Fri Sep 01, 2006 12:10 am Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
Frederick Gotham wrote:
| Quote: | I don't have Bjarne's book here with me, so I can't look over the code
snippet. Perhaps he used reinterpret_cast simply because it slipped his
mind
that static_cast would get the job done.
|
In the following code, is null preserved?
main () {
void* pv = 0;
if (static_cast<int*>(pv) == 0)
cout << "null preserved";
}
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Josef Svitak
Guest
|
| Posted: Fri Sep 01, 2006 12:18 am Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
andrew_nuss (AT) yahoo (DOT) com wrote:
| Quote: | I've noticed that on pg. 342 of Stroustups "C++ Programming Language"
book his example of using partial specialization for a custom vector
template where T is a pointer to anything to avoid bloat, he uses
reinterpret_cast to go back and forth between void* and T* pointers.
Why? Why not use static_cast?
|
This has been fixed in the "Special Edition" to use static_cast.
And I'd have to agree with Mr. Gotham that you should probably verify
_before_ making blanket code changes ;)
josef
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
andrew_nuss@yahoo.com
Guest
|
| Posted: Fri Sep 01, 2006 12:19 am Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
Frederick Gotham wrote:
| Quote: | I don't have Bjarne's book here with me, so I can't look over the code
snippet. Perhaps he used reinterpret_cast simply because it slipped his
mind
that static_cast would get the job done.
|
It can get pretty complex for me, namely I also want to store 2 types
of pointers in a virtual hierarchy as void* and then retrieve it and
narrow it to the base class pointer. The question in the following
hierarchy of widening to an interface from 2 different derivations, and
then further widening to void*, and then being able to narrow back from
void* to the interface, what's better than my use of
reinterpret_cast<>.
class Arc;
struct ArcLink {
virtual Arc* ThisArc () = 0;
virtual ArcLink* NextLink () = 0;
};
class Arc : public ArcLink {
... some data members
public:
virtual Arc* ThisArc () { return this; }
virtual ArcLink* NextLink() { return 0; }
... additional functionality
};
class ArcLinkImpl : public ArcLink {
Arc* arc;
ArcLink* tail;
public:
virtual Arc* ThisArc () { return arc; }
virtual ArcLink* NextLink () { return tail; }
};
// from utilities for a red-black set
struct IntSetElem {
void* obj;
private:
IntSetElem* left;
IntSetElem* right;
int key;
bool color;
};
// and the question is, what casts to and from elem->obj
main () {
IntSetElem* elem1 = ...; // get an element from a set
IntSetElem* elem2 = ...; // get another
Arc* arc = ...; // create an arc
ArcLinkImpl* arclink = ...; // create an arclink
ArcLink* intf = arc; // widen
elem1->obj = reinterpret_cast<void*>(intf);
//??? can I pass arc directly to the cast here
intf = arclink; // a different widen
elem2->obj = reinterpret_cast<void*>(intf);
//??? can I pass arclink directly to the cast here
// now fetch Arc* as ArcLink*
intf = reinterpret_cast<ArcLink*>(elem1->obj);
// I bet this is ok because I made sure to stuff it
// as an ArcLink* interface pointer
// what's better???
// now fetch ArcLinkImpl* as ArcLink*
intf = reinterpret_cast<ArcLink*>(elem2->obj);
// again ok because I stuffed the ArcLinkImpl*
// as an ArcLink*
// what's better???
}
Andy
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Seungbeom Kim
Guest
|
| Posted: Fri Sep 01, 2006 12:20 am Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
Frederick Gotham wrote:
| Quote: | andrew_nuss (AT) yahoo (DOT) com posted:
As a result of his example, I have decided throughout my program to use
reinterpret_cast to go back and forth between void* and typed pointers.
Why adopt someone else's style before you even understand why? It is not a
good way to learn.
|
Because it's from a textbook, a very renowned one.
Looking back on my early days, I realise that reading others' codes
(including the style) and imitating them have been quite an effective way
to learn programming, even when I could not understand all of them.
Hence the importance of good-style examples in textbooks, and it comes to
me as a surprise that Stroustrup used reinterpret_cast where he didn't
have to, while explaining in another part of the same book that the new-
style casts were named so ugly that it could discourage their use.
--
Seungbeom Kim
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Erik Max Francis
Guest
|
| Posted: Fri Sep 01, 2006 5:44 am Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
andrew_nuss (AT) yahoo (DOT) com wrote:
| Quote: | As a result of his example, I have decided throughout my program to use
reinterpret_cast to go back and forth between void* and typed pointers.
I use static_cast only when narrowing to a derived type from a base
class type.
Can anyone give me the decisive opinion on this issue with
reinterpret_cast and void*, and in particular, why Stroustup uses
reinterpret_cast instead of static_cast?
|
It's a typo. It's corrected in later editions; the snippet of code on
p. 342 of my third edition doesn't contain any reinterpret_casts.
In other words, it's a pretty good idea to make sure you understand
_why_ something is done before you start doing it yourself. Even
respected texts contain errors, and furthermore, even experts sometimes
get things wrong.
--
Erik Max Francis && max (AT) alcyone (DOT) com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
Would a harvest from my heart / Find its season
-- Sandra St. Victor
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Greg Herlihy
Guest
|
| Posted: Fri Sep 01, 2006 5:46 pm Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
andrew_nuss (AT) yahoo (DOT) com wrote:
| Quote: | Hi,
I've noticed that on pg. 342 of Stroustups "C++ Programming Language"
book his example of using partial specialization for a custom vector
template where T is a pointer to anything to avoid bloat, he uses
reinterpret_cast to go back and forth between void* and T* pointers.
Why? Why not use static_cast?
1) he made a mistake (unlikely)
|
A mistake is indeed unlikely. So logically, we can speculate that using
reinterpret_cast at the time this example was written - was likely not
a mistake in C++.
| Quote: | 2) does static_cast with complicated T* to void* cause address shifts?
If so this could cause problems with preservation of a NULL value as
well as a round-trip inconsistency. My feeling is that
reinterpret_cast simply will not change the actual pointer value stored
from the assembly perspective in either direction, which is desired.
|
If changing the actual pointer value is undesirable - why would a
static_cast change the pointer value any more than reinterpret_cast? A
void pointer can be a pointer to any type - so with each type just as
likely as the other, would we not expect either cast to leave the
pointer's value unchanged?
| Quote: | 3) is it because of ever so slightly better performance?
|
Not a chance.
| Quote: | As a result of his example, I have decided throughout my program to use
reinterpret_cast to go back and forth between void* and typed pointers.
I use static_cast only when narrowing to a derived type from a base
class type.
|
I'm afraid you that you fell victim to the "argument from authority"
logical fallacy (or, for those more familiar with its Latin name: the
"argumentum ad verecundiam'' or simply the "ipse dixit" line of
reasoning. Wikipedia has a good article on this all-too-common fallacy:
http://en.wikipedia.org/wiki/Appeal_to_authority .
| Quote: | Can anyone give me the decisive opinion on this issue with
reinterpret_cast and void*, and in particular, why Stroustup uses
reinterpret_cast instead of static_cast?
|
I have no idea of the actual reason - nor do I think the the issue is
particularly significant. But I would guess that - at the time - the
names of the cast operators were not yet final, so a retroactive
"mistake" was always a possibillity once the cast operators were given
names. Furthermore, choosing one or the other cast won't make any
difference to how the program runs. So rather than spend too much time
agonizing over whether to use reinterpret_cast or static_cast is the
correct choice - just pick one and move on to finishing the rest of the
program. Because - while it is true that every programmer should strive
to write correct code - it also true that no program good enough to
ship has likely ever been delayed in order for its programmers to have
time to make editorial corrections and other cosmetic improvements to
its source code.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Thomas Richter
Guest
|
| Posted: Fri Sep 01, 2006 5:49 pm Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
andrew_nuss (AT) yahoo (DOT) com wrote:
| Quote: | In the following code, is null preserved?
main () {
void* pv = 0;
if (static_cast<int*>(pv) == 0)
cout << "null preserved";
}
|
Yes, of course.
So long,
Thomas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Thomas Richter
Guest
|
| Posted: Fri Sep 01, 2006 5:49 pm Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
andrew_nuss (AT) yahoo (DOT) com wrote:
| Quote: | It can get pretty complex for me, namely I also want to store 2 types
of pointers in a virtual hierarchy as void* and then retrieve it and
narrow it to the base class pointer.
|
Possibly a not very C++ way to approach the problem. Is this time
critical? If not, you could provide a virtual "getPointer()" method
(please choose a better name) in the base class that returns the common
base of the two objects, and use covariance to specialize this method in
the derived classes. Alternatively, use a container that is templated to
the class you want to store in.
| Quote: | The question in the following
hierarchy of widening to an interface from 2 different derivations, and
then further widening to void*, and then being able to narrow back from
void* to the interface, what's better than my use of
reinterpret_cast<>.
class Arc;
struct ArcLink {
virtual Arc* ThisArc () = 0;
virtual ArcLink* NextLink () = 0;
};
class Arc : public ArcLink {
... some data members
public:
virtual Arc* ThisArc () { return this; }
virtual ArcLink* NextLink() { return 0; }
... additional functionality
};
class ArcLinkImpl : public ArcLink {
Arc* arc;
ArcLink* tail;
public:
virtual Arc* ThisArc () { return arc; }
virtual ArcLink* NextLink () { return tail; }
};
// from utilities for a red-black set
struct IntSetElem {
void* obj;
private:
IntSetElem* left;
IntSetElem* right;
int key;
bool color;
};
|
This should probably be a template where the templare parameter
describes the object pointed to. Alternatively, why not use an
already available container from the STL or Boost? Which kind of
operations do you need for IntSetElem?
| Quote: | // and the question is, what casts to and from elem->obj
main () {
IntSetElem* elem1 = ...; // get an element from a set
IntSetElem* elem2 = ...; // get another
Arc* arc = ...; // create an arc
ArcLinkImpl* arclink = ...; // create an arclink
ArcLink* intf = arc; // widen
elem1->obj = reinterpret_cast<void*>(intf);
//??? can I pass arc directly to the cast here
|
No cast is needed here, though maybe you would like to use an
IntSetElem<ArcLink> here?
| Quote: | intf = arclink; // a different widen
|
This works.
| Quote: | elem2->obj = reinterpret_cast<void*>(intf);
//??? can I pass arclink directly to the cast here
|
No cast required. Every pointer can be converted to a void *
without a cast.
| Quote: | // now fetch Arc* as ArcLink*
intf = reinterpret_cast<ArcLink*>(elem1->obj);
|
Bad idea. Either use the template idea, or use a static_cast<>.
You do not care about the "raw bit pattern" of the pointer here. What
you want to tell the compiler is to narrow the pointer to a more
specific object.
| Quote: | // I bet this is ok because I made sure to stuff it
// as an ArcLink* interface pointer
// what's better???
|
To use an already available container, likely.
| Quote: | // now fetch ArcLinkImpl* as ArcLink*
intf = reinterpret_cast<ArcLink*>(elem2->obj);
// again ok because I stuffed the ArcLinkImpl*
// as an ArcLink*
// what's better???
|
No cast at all if you can avoid it. If elem2 would be an
IntSetElem<ArcLink> and would be declared as follows:
template<class T>
struct IntSetElem {
T* obj;
private:
IntSetElem* left;
IntSetElem* right;
int key;
bool color;
};
no cast whatsoever would be required, and type-correctness would
be guaranteed by the compiler.
By the way: Why is this a struct? And are you sure the compiler
generated copy and assignment operators are what you want?
So long,
Thomas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Fri Sep 01, 2006 5:58 pm Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
andrew_nuss (AT) yahoo (DOT) com wrote:
| Quote: | Frederick Gotham wrote:
I don't have Bjarne's book here with me, so I can't look
over the code snippet. Perhaps he used reinterpret_cast
simply because it slipped his mind that static_cast would
get the job done.
In the following code, is null preserved?
main () {
void* pv = 0;
if (static_cast<int*>(pv) == 0)
cout << "null preserved";
}
|
All pointer casts preserve null.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Fri Sep 01, 2006 5:59 pm Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
andrew_nuss (AT) yahoo (DOT) com wrote:
| Quote: | Frederick Gotham wrote:
I don't have Bjarne's book here with me, so I can't look
over the code snippet. Perhaps he used reinterpret_cast
simply because it slipped his mind that static_cast would
get the job done.
It can get pretty complex for me, namely I also want to store
2 types of pointers in a virtual hierarchy as void* and then
retrieve it and narrow it to the base class pointer.
|
Both static_cast to void and reinterpret_cast have the
constraint that you must cast the pointer back to the original
type if they are to work. In your case, you should explicitly
narrow the pointer before converting it to void*, then cast back
to the narrowed type.
| Quote: | The question in the following hierarchy of widening to an
interface from 2 different derivations, and then further
widening to void*, and then being able to narrow back from
void* to the interface, what's better than my use of
reinterpret_cast<>.
class Arc;
struct ArcLink {
virtual Arc* ThisArc () = 0;
virtual ArcLink* NextLink () = 0;
};
class Arc : public ArcLink {
... some data members
public:
virtual Arc* ThisArc () { return this; }
virtual ArcLink* NextLink() { return 0; }
... additional functionality
};
class ArcLinkImpl : public ArcLink {
Arc* arc;
ArcLink* tail;
public:
virtual Arc* ThisArc () { return arc; }
virtual ArcLink* NextLink () { return tail; }
};
// from utilities for a red-black set
struct IntSetElem {
void* obj;
private:
IntSetElem* left;
IntSetElem* right;
int key;
bool color;
};
// and the question is, what casts to and from elem->obj
main () {
IntSetElem* elem1 = ...; // get an element from a set
IntSetElem* elem2 = ...; // get another
Arc* arc = ...; // create an arc
ArcLinkImpl* arclink = ...; // create an arclink
ArcLink* intf = arc; // widen
|
I would have thought that that was narrowing.
| Quote: | elem1->obj = reinterpret_cast<void*>(intf);
//??? can I pass arc directly to the cast here
|
You don't need the cast. Note, however, that to use the void*
(other than copying it), you must first convert it to an
ArcLink* (I'd use static_cast for this), or you have undefined
behavior.
| Quote: | intf = arclink; // a different widen
|
Again, you're using widen for the operation you described as
narrowing in the text at the top. This is derived to base.
| Quote: | elem2->obj = reinterpret_cast<void*>(intf);
//??? can I pass arclink directly to the cast here
|
Of course. Why would it be different than the previous case.
| Quote: | // now fetch Arc* as ArcLink*
intf = reinterpret_cast<ArcLink*>(elem1->obj);
// I bet this is ok because I made sure to stuff it
// as an ArcLink* interface pointer
// what's better???
|
I'd use static_cast.
This is fine: you stored an ArcLink*, and you cast back to the
same type.
| Quote: | // now fetch ArcLinkImpl* as ArcLink*
intf = reinterpret_cast<ArcLink*>(elem2->obj);
// again ok because I stuffed the ArcLinkImpl*
// as an ArcLink*
// what's better???
|
As above.
I'd still be very leary of this. It's all too easy to forget
the passage through ArcLink* when storing the pointer, and then
it won't work---static_cast or reinterpret_cast when extracting
the pointer. Wrap IntSetElem in a class which takes ArcLink*
pointers, so the user cannot set the pointers without converting
his pointers to ArcLink*.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Frederick Gotham
Guest
|
| Posted: Sat Sep 02, 2006 1:29 am Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
Greg Herlihy posted:
| Quote: | A mistake is indeed unlikely. So logically, we can speculate that using
reinterpret_cast at the time this example was written - was likely not
a mistake in C++.
|
A bit extreme don't you think... ? Programmers make mistakes here and there
-- but we catch them when we read back over our code.
I _know_ that static_cast is the one for the job, so my first guess would be
that Bjarne made a mistake by using reinterpret_cast. But then again,
there's
no observable difference in the final program.
--
Frederick Gotham
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sun Sep 03, 2006 5:57 am Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
Greg Herlihy wrote:
| Quote: | andrew_nuss (AT) yahoo (DOT) com wrote:
I've noticed that on pg. 342 of Stroustups "C++ Programming Language"
book his example of using partial specialization for a custom vector
template where T is a pointer to anything to avoid bloat, he uses
reinterpret_cast to go back and forth between void* and T* pointers.
Why? Why not use static_cast?
1) he made a mistake (unlikely)
A mistake is indeed unlikely. So logically, we can speculate that using
reinterpret_cast at the time this example was written - was likely not
a mistake in C++.
|
It's not really a mistake today, since it has the same effect as
static_cast in this context.
Still, Stroustrup is human (and I think he'd be the last to deny
it). Typos occur, and he's not immune to them, any more than
you or I are. He corrected it in later editions; I'd consider
that a recognition on his part that there was a mistake.
| Quote: | 2) does static_cast with complicated T* to void* cause
address shifts? If so this could cause problems with
preservation of a NULL value as well as a round-trip
inconsistency. My feeling is that reinterpret_cast simply
will not change the actual pointer value stored from the
assembly perspective in either direction, which is desired.
If changing the actual pointer value is undesirable - why
would a static_cast change the pointer value any more than
reinterpret_cast?
|
Because it does. Not when casting to and from a void*, but when
casting up and down in an inheritance hierarchy.
| Quote: | A void pointer can be a pointer to any type - so with each
type just as likely as the other, would we not expect either
cast to leave the pointer's value unchanged?
|
Strictly speaking: the standard does not require that the
address of a non-POD object point to the first byte of that
object; an implementation could place the vptr at the address -
4, or some such. In which case, both reinterpret_cast and
static_cast will change the physical address. (Presumable, in
the case of reinterpret_cast, because of course, all that the
standard requires is that you can cast it to void* and back to
the original type.) In practice, I've never heard of such an
implementation.
[...]
| Quote: | I have no idea of the actual reason - nor do I think the the
issue is particularly significant. But I would guess that - at
the time - the names of the cast operators were not yet final,
so a retroactive "mistake" was always a possibillity once the
cast operators were given names.
|
The names were finalized very early, if I remember correctly.
On the other hand, our instincts as to which cast is correct
didn't really develope until after that.
| Quote: | Furthermore, choosing one or the other cast won't make any
difference to how the program runs.
|
But it will affect how a maintenance programmer sees the code.
Which is, in many cases, just as important.
--
James Kanze (Gabi Software) email: kanze.james (AT) neuf (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
bjarne
Guest
|
| Posted: Tue Sep 05, 2006 7:25 pm Post subject: Re: stroustrup, void*, and reinterpret_cast |
|
|
Diego Martins wrote:
| Quote: |
But it is WRONG to use reinterpret_cast in this example?
In my programs, I use reinterpret_cast to cast to void * and cast back
to the original pointer type.
Are there any drawbacks using this approach? What does static_cast buy
me in this case?
|
Not wrong, just unwise. When you use reinterpret_cast you can make
mistakes that are impossible using static_cast and using static_cast,
you can make mistakes that are impossible using C-style cast. Thus, by
using the "least powerful" cast that can do the job, you minimize
errors and the likelyhood of maintenance errors. In particular,
reinterpret_cast can convert between pointers and integers - something
you wouldn't want to happen by accident.
See http://www.research.att.com/~bs/bs_faq2.html#static-cast
Also, when you use static_cast, you stay within the semantics of the
language; when you use reinterpret_cast, you play with bits (the
representation). By doing static_cast<int*>(pv) when pv is a void*, you
assume that a void* is represented in exactly the same ways as an int*.
That's by far the most common, but not guaranted.
-- Bjarne Stroustrup; http://www.research.att.com/~bs
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
