Вы правы, использования const_cast
часто указывает на недостаток дизайна, или API, который находится вне вашего контроля.
Однако есть исключение, оно полезно в контексте перегруженных функций. Я цитирую пример из книги C++ Primer:
// return a reference to the shorter of two strings
const string &shorterString(const string &s1, const string &s2)
{
return s1.size() <= s2.size() ? s1 : s2;
}
Эта функция принимает и возвращает ссылки на const string
. Мы можем вызывать функцию по парам неконстантных аргументов string
, но в результате мы получим ссылку на const string
. Возможно, мы захотим иметь версию shorterString
, которая при заданных аргументах, отличных от const, дала бы простую ссылку. Мы можем написать эту версию нашей функции с помощью const_cast
:
string &shorterString(string &s1, string &s2)
{
auto &r = shorterString(const_cast<const string&>(s1),
const_cast<const string&>(s2));
return const_cast<string&>(r);
}
Этой версия вызывает константные версии shorterString
литья своих аргументов ссылок на const
. Эта функция возвращает ссылку на const string
, которую мы знаем связано с одним из наших исходных, неконстантных аргументов. Поэтому мы знаем, что безопасно отбрасывать эту строку обратно на равную string&
в обратном направлении.
Это то же самое, что с 'reinterpret_cast',' union', 'memcpy' и многими другими: всегда есть способ обойти механизмы безопасности на C++, в основном ссылаясь на неопределенное поведение. То, что вы можете их разбить, не означает, что эти механизмы не приносят пользы. – dyp
«То, что он объявил как const, не будет изменен в любом случае?» По соглашению, объект, сконструированный 'const', не изменит свое * наблюдаемое поведение *. Это не значит, что его биты не будут изменены. – dyp
Ленивая оценка (http://stackoverflow.com/questions/881119/dealing-with-lazy-comput-in-c-classes), но, вероятно, использование mutable лучше, чем, например, const_cast <...> (это). – user2672165