C++, casting and const

Quote:

Original post by Ryan_001 Can I use reinterpret_cast to add or remove const-ness? Now I know const_cast can, but more specifically is something like the following kosher? void PrintInt (const void* p) { cout << *reinterpret_cast<const int*>(p) << endl; }int a = 5;const int b = 6;PrintInt(&a);PrintInt(&b); From what I understand, reinterpret_cast is only valid if you cast the pointer back to its original type, but does the const modifier play into this (and what about volatile)? The above code example works in MSVC, but just cause it works doesn't mean its proper C++.

Quote:

but does the const modifier play into this (and what about volatile)?

std::cout <<(&type) <<std::endl;

Quote:

Original post by Red Ant Beware that casting to or from void* is almost never a good idea since it completely chucks type safety out the window.

Quote:

Original post by CmpDev As pointed out reinterpret_cast is the wrong operator to use here and Sicrane has already pointed out const_cast but that may require using along with static_cast.

Quote:

Original post by CmpDev Currently your code is undefined/implementation specific; reinterpret_cast is rather limited in what it guarantees and allows.

Quote:

Original post by CmpDev Quote: but does the const modifier play into this (and what about volatile)? With respect to the void pointer, no this does not have any effect but it does have an effect for the type before it was implicitly cast to void const*. You are not casting back to the orignal type.

Quote:

Original post by CmpDev Don't use void pointer unless you must, I see no reason to use it here as the following does what you want. *** Source Snippet Removed ***

Quote:

Original post by BitMaster Anything you do via static_cast in C++ does not throw away type safety (in general it's just there to avoid a warning).

class Foo{};class Bar : public Foo{  float a;};class Car : public Foo{  int a;};Foo* f = new Bar();Car* c = static_cast<Car*>(f);

Quote:

Original post by BitMaster Anything you do via const_cast does not throw away type safety (provided you can guarantee the data is never written to, so for example a compatibility layer with C code can use it).

Quote:

Original post by BitMaster dynamic_cast does not throw away type safety (and cannot work with a void* pointer to begin with).

Quote:

The only place where type safety goes out the window is the dreaded reinterpret_cast.

Quote:

Original post by RobTheBloke Quote: Original post by CmpDev As pointed out reinterpret_cast is the wrong operator to use here and Sicrane has already pointed out const_cast but that may require using along with static_cast. No he didn't. He said const_cast is required to remove const. Since this case doesn't require the removal of const, the correct cast would be static_cast.

Quote:

Original post by RobTheBloke Quote: Original post by CmpDev Currently your code is undefined/implementation specific; reinterpret_cast is rather limited in what it guarantees and allows. Uhm, reinterpret_cast has no limitations. It's the most limitation free of all the casts. It's not undefined behaviour either, quite the opposite infact... There will be an integer at the memory location referenced by p (although care has to be taken to ensure you use the function correctly since it's without type checking).

Quote:

Original post by RobTheBloke Quote: Original post by CmpDev Quote: but does the const modifier play into this (and what about volatile)? With respect to the void pointer, no this does not have any effect but it does have an effect for the type before it was implicitly cast to void const*. You are not casting back to the orignal type. void const* and const void* are not the same types.

Quote:

Original post by RobTheBloke volatile does not come into play here (and won't do unless you start using multiple threads).

Quote:

Original post by RobTheBloke Quote: Original post by CmpDev Don't use void pointer unless you must, I see no reason to use it here as the following does what you want. *** Source Snippet Removed *** Lol. It's definitely not what he wants....

Quote:

Original post by RobTheBloke void const* and const void* are not the same types.

Quote:

Original post by CmpDev volatile has nothing todo with threads but that is another topic.

Quote:

Original post by Shinkage Edit2: Okay, this too... Quote: Original post by CmpDev volatile has nothing todo with threads but that is another topic. This isn't true either. Volatile specifically says "other threads/processes may modify this" so that the compiler won't screw things up with optimizations.

Quote:

Original post by RobTheBloke Quote: Original post by Red Ant Beware that casting to or from void* is almost never a good idea since it completely chucks type safety out the window. Uhm. All casts throw away type safety. That's it's purpose in life. To throw away the type safety of the language because *you know better*.... ;)

Quote:

Original post by Red Ant Quote: Original post by Shinkage Edit2: Okay, this too... Quote: Original post by CmpDev volatile has nothing todo with threads but that is another topic. This isn't true either. Volatile specifically says "other threads/processes may modify this" so that the compiler won't screw things up with optimizations. No, it doesn't. Well, it may but that depends on what compiler / OS you're using. EDIT: Read the "In C and C++" section of this Wikipedia article. http://en.wikipedia.org/wiki/Volatile_variable

Quote:

Original post by Shinkage Okay, well, in GCC and MSVC it works more or less the way I described. It tells the compiler that "this variable may be modified elsewhere" so the compiler doesn't assume it can just stick it in a register and use it from there. Whether that's because it's mapped to the hardware or because another thread does so, the effect is the same. Not really familiar with any compilers that treat it differently from that, but it definitely does have something to do with threading. Your Wikipedia citation is true, but somewhat irrelevant. I didn't (and wouldn't) claim that volatile can be relied on for atomic access or proper sequencing, just that it is not unrelated to threads, as had been earlier claimed. User beware.

Quote:

Original post by ApochPiQ According to the standard, all volatile does is prevent reordering of instructions that access the variable, and enforces that the variable is read or written to exactly once for every access written in the original code. By the standard, then, volatile indeed has nothing to do with threading.

int a = 5;void* b = &aint c = *reinterpret_cast<int*>(b);

Quote:

Original post by ApochPiQ volatile is almost always the wrong thing to use, especially when threading is concerned.

Quote:

Original post by Ryan_001 Whether it be message passing, mutex's, critical sections, barriers, or what-have-you, they all rely on volatile under the hood don't they?

Quote:

Apart from going straight down to assembly or calling as OS supplied routine (both of which are undefined/implementation specific) you don't have a lot of other options.

Quote:

Original post by Ryan_001 This has gone far beyond the original question, that said thanks for all the responses. There seems to be alot of disagreement on what reinterpret_cast can safely do. Now I know shouldn't use it, and I don't in normal code, more I was just curious on what it can do. It seems a bit silly that any use of reinterpret_cast would be undefined/implementation specific, but perhaps I'm wrong here? I was under the impression casting through reinterpret_cast and back, as long as the alignment and size of the intermediate was appropriate, that you can safely (and in a defined/non-implementation specific way) get the original value back (whatever that may be), and use it. For example: int a = 5;void* b = &aint c = *reinterpret_cast<int*>(b); is undefined?

f( a(), b() );

f( ++(*a), ++(*b) );