Archived

This topic is now archived and is closed to further replies.

You can explicitly cast away a const... doest that defeat the point?

This topic is 5089 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Recently I was using the function string::c_str() which returns a const char* with a Direct X Fuction. The function however needed a char*. It was looking like I would need to copy the string just to pass a filename to the function, but then I tryed casting it to a char* and to my surprise it worked. Now doesnt that defeat the purpose of the const directive? I thought the whole point was so that people using a function can be assured that values they pass to it wont be changed, but if you can cast the const away, then doesnt that evaporate that idea into thin air?

Share this post


Link to post
Share on other sites
You can do whatever you want to a pointer, cast it to different types if you want, but its a very dangerous thing to do and you should be aware of the repercussions.

some platforms may put const data variables in read only memory so even if you cast away the const, a write still wont work, you need to be completely sure *why* your casting away the const, if its simply to call a function that doesnt modify the contents but isnt flagged as const, its okay.

and this is also why the const_cast<> was added to make it explicit as to why the cast is there and what its doing


Share this post


Link to post
Share on other sites
Don''t cast a c_str() to (char*), you don''t know what would happen to the string if something else changed the internals of it.

Being able to get rid of the const by casting was a decision; it assumes that the programmer has enough sense to know what he/she is doing.

Share this post


Link to post
Share on other sites
The const char* to char* cast can be made implicitly, for other types you have to do a cons_cast. The reason char* is treated differently is backward compatibility for C code (as is the case with most crazy features in C++). In C, may people would do something like char* name = "John" , while a literal string like this is really a const char*, some c libraries also take char*''s when they really need a const char*. Be VERY wary with this stuff though, modifying things that are supposed to be const can make your program blow up.

(i might be wrong here, it''s been a while since i read this, but i read it on several different places and i am pretty sure about it)

Share this post


Link to post
Share on other sites
The usual reason to use const_cast is that some function was
written to incorrectly expect char * instead of const char *
when the function doesn''t modify the parameter at all. (You
can substitute "char" with any other data type, and also *
with &.)

So, inside a const member function, you''d need to cast
away the const-ness of a member variable in order to call
those incorrectly written functions. (Or declare the
member variable as "mutable".)

const_cast should *never* be used to write to variables that
were declared const. The also applies to trying to call
functions that DO modify the parameter.




Kami no Itte ga ore ni zettai naru!

Share this post


Link to post
Share on other sites
Remember that const isn''t actually part of the original C standard (it might be now, not sure).

So most C api''s that accept char*''s probably should accept const char*''s instead.


daerid | Legends | Garage Games | Spirit | Hapy | Boost | Python | Google
"Doomed to crumble, unless we grow, and strengthen our communication" - Maynard James Keenan, Tool

Share this post


Link to post
Share on other sites
You can also circumvent the ''protected'' or ''private'' directive if you really want. Let''s say you have a class A that has private members. Just make a new class A2 that has the same members as A, except everything is public. Then take a pointer to the object of type A, cast it as a pointer to type A2, and you can access everything in A.

The point is: these language features are not security features, they are more like strong guidelines. They don''t give you complete protection against malicious or ignorant programmers.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Yep, DevIL does this and the author won''t change it as the library is no longer supported. It''s reasons like this that C++ has to maintain backward compatibility with C - hmmm... would be interesting to see a compiler that doesn''t care about C.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by daerid
Remember that const isn''t actually part of the original C standard (it might be now, not sure).



Incorrect. const was in the ANSI C standard from the beginning (the first official standard for C). const wasn''t in C prior to the standard, though.

Share this post


Link to post
Share on other sites