Yes you were right, it does depend on the compiler, and it also depends on a few issues. For example in C++ (in Racoon's defense kinda) it is possible, though highly frowned upon, to modify a constant. Really the only reason for that feature to exist is to be compatible with old code that didn't use constants for certain things. For example, if you are familiar with the std::string class, when you use the std::string::c_str function, it returns a const char *, old C programs use char *, not const char *. So if you try and pass a const char * when a char * is expected, C++ complains, so the const_cast<>() operator was introduced. If you use this operator, and again it is frowned on, the compiler will NOT discard those kind of statements because it is possible that the value might change. As for if you just use it in a normal sense of always being constant, assuming you use g++ on Linux, and a semi-recent version (3.x) it will most likely optimize unneeded statements like that away. I even saw one compiler, though I can't remember the name, that in the situation you described it would generate a message like "constant is set to 0, yet expected to be 1" or something to that effect to let you know that the particular statement is probably a programming error. The way I described it is a bit more simple than it really is, a good compiler will do more checking than what I said, some will even remove it even if const_cast<>() is used if it determines that the value isn't modified. Basically, assume that it might remove it, but don't expect that it will.
