Isn't that what static_cast is for? const_cast sounds like the
wrong tool for the job (because common C++ wisdom dictates
that static_cast is good and const_cast should usually be
avoided if possible).
That's a good point. As Pete said, const_cast is for adjusting
const, and that's what you're doing. But IMHO, it's arguable
both ways:
-- If you use static_cast, you can't accidentally add const
(but is this really a problem?). Also, it won't show up if
someone greps for const_cast (which they're doubtlessly
doing to find "dangerous" code, and adding const isn't
dangerous).
-- If you use const_cast, you can't accidentally perform a
Derived* to Base* (or worse, a Base* to Derived*) conversion
which you didn't want.
IMHO, that second point predominates, and is, ultimately, the
reason why the new style casts were introduced: const_cast
allows adjusting const-ness, with no risk of accidentally
performing any other conversion, static_cast allows moving up
and down in the hierarchy, without any risk of accidentally
removing const-ness or type punning, and reinterpret_cast forces
type punning (even if the types involved are pointers within an
inheritance hierarchy), without any risk of removing const-ness.
You may as well say "if you want to add constness eg. for
overload resolution, use reinterpret_cast". That's just wrong.
Agreed. Using static_cast or reinterpret_cast to adjust
const-ness, even when they allow it (i.e. adding const) is just
wrong.