Const_cast? What's that?

Lews

void* const_ptr_too_normal_ptr(const void* ptr){
stringstream ss;
ss << (int)ptr;

int temp;

ss >> temp;
return (void*)(temp);
}

Somebody hold me

ammoQ

I'm not a C++ pro, but something tells me there must be a better way than that ;-)

The intention of the code is clear: make a modifyable copy of a pointer. Most likely a WTF, because people use const pointers for a reason.

Silex

lol what an inneficient way :)

The WTF is that the guy is good enough to know about stringstream but couldn't write :

void* const_ptr_too_normal_ptr(const void* ptr)
{
return (void*) ptr;
}

Not knowing about const_cast<void*>(ptr) is half-understandable, but not understanding that his return (void*)(temp) is what is actually removing the const is fucked up.

ammoQ

@Silex said:

lol what an inneficient way :)

The WTF is that the guy is good enough to know about stringstream but couldn't write :

void* const_ptr_too_normal_ptr(const void* ptr)
{
return (void*) ptr;
}

Not knowing about const_cast<void*>(ptr) is half-understandable, but not understanding that his return (void*)(temp) is what is actually removing the const is fucked up.

wouldn't the compiler complain about the cast?

Silex

@ammoQ said:

wouldn't the compiler complain about the cast?

No. At least not on my compiler.

I guess some compilers might issue a warning but usually when you do a C cast you're just doing a "shut the compiler up" strategy.

C++ casts are prefered to C casts because they do only one concept, when (TYPE) can have 3 differents meaning : remove the constness / convert to type / make x be seen as y.

dhromed

@ammoQ said:

I'm not a C++ pro, but something tells me there must be a better way than that ;-)

The intention of the code is clear: make a modifyable copy of a pointer. Most likely a WTF, because people use const pointers for a reason.

But doesn't this function just create a new pointer to the same variable?

Couldn't you just do that by assigning the const pointer to a new var? Or would that create a pointer to a pointer?

I'm not hip to explicit pointer-based programming styles. :)

lluthor

@dhromed said:

But doesn't this function just create a new pointer to the same variable?

Couldn't you just do that by assigning the const pointer to a new var? Or would that create a pointer to a pointer?

I'm not hip to explicit pointer-based programming styles. :)

The pointer is already not const. Its the data its pointing at which is const, and you cannot cast away that qualifier without casting explicitly. Getting rid of const or volatile is what const_cast<> is for. Chances are this was done to silence an annoying compiler warning, and simply doing it the C way is not going to do that.

Lews

@Silex said:

Not knowing about const_cast<void*>(ptr) is half-understandable, but not understanding that his return (void*)(temp) is what is actually removing the const is fucked up.

Actually, that's not removing the const. He takes the address of the const pointer, and turns it into a string. Then he reads that string back into an integer. Then he returns the value of the integer as a pointer.

There are simply so many things wrong with this function, it's hard to take it in at once. You sort of have to cover part of the screen so you don't go mad :P

mschramp

Other examples try to cast const away. The example below shows why this is not good, no matter which approach you take:

#include <stdio.h> void doIt(const int& x)
{
int& c = const_cast<int&>(x);
c++;
}
int main(int argc , char * argv[])
{
// The code below is legal as in: the compiler won't complain
// It's not really legal: the ++ operator tries to increase a value in
// a static const array, many compilers will put this in a read-only
// memomy segment.
static const int array[] = { 10, 20 , 30 };
doIt(array[2]); printf ("%d\n", array[2]);
return 0;
}

Special cast_const<xxx> operators won't save your life here.

The big rule applies here: if you need a non-const object then either copy the object, specify your API that it requires a non-const object or (aarghhh) use the mutable attribute for those occasions where you are in a const method but your object isn't (e.g. if an object is const, but uses internal objects to hold expensive data that can be cached then the cache is usually a mutable object that can can be changed in a const method)

MaHuJa

// Warning: Application-Breaking code ahead. Think very carefully before you use it. Successful tests will be inconclusive.
template <typename T> T* unconst (const T* in) { return const_cast<T*>(in); }

// Keeping typesafety too.

lokedhs

Not only is this code really crazy and breaks a whole bunch of rules in the standard, the fact that he stores the pointer in an int will cause it to crash when it's compiled on most 64-bit systems.

(for those of you who don't know, on an LP64 architecture, an int is 32 bits and a pointer is 64 bits. The standards say what they do for a reason).

Zlodo

Anyway...

const_cast was intended to solve interfacing issues between C++ code and old, C code that didn't have const.

Some perverted programmers use it as a quick and dirty fix for their poorly thought out code. I say perverse, because if you know enough about C++ to know about const_cast, you should know better than using it as a quick fix.

But even more perverse programmers do this:

 class SomeClass
 {
...
 void SomeMethod() const;
...
 }

So you, maintaining the thing and looking for potential causes for a bug, see this and think "alright, this method is not where the state of the object was fucked up then".
Then, just in case, you look up the implementation of the method and discover the so nice and pretty surprise hidden there by the retard who wrote the code in the first place:

void SomeClass::SomeMethod() const
{
 SomeClass* pThis = const_cast< SomeClass* >( this );

 ...
}

Thanks for lying in the prototype, man.

As a side note, that same guy managed to find out about placement new and managed to find a perverted way to use it too:

new (this) ( whatever );