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

Started by
10 comments, last by Negitivefrags 20 years, 3 months ago
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?
Advertisement
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


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.
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)
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!
神はサイコロを振らない!
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
daerid@gmail.com
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.
It''s called syntactic salt: potentially dangerous things should be hard to do accidentally.


"Without deviation, progress itself is impossible." -- Frank Zappa
"There is only one everything"
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.
Const-Correctness
Difficulty: 6 / 10

Always use const as much as possible, but no more. Here are some obvious and not-so-obvious places where const should be used -- or shouldn''t.


Casts
Difficulty: 6 / 10

How well do you know C++''s casts? Using them well can greatly improve the reliability of your code.


Constant Optimization?
Difficulty: 3 / 10

Does const-correctness help the compiler to optimize code? Most programmers'' reaction is that, yes, it probably does. Which brings us to the interesting thing...

This topic is closed to new replies.

Advertisement