Достоинства static_cast

[Igors]

Добрый день

Навеяно этим

Поэтому в C++ специально сделали безопасный статик_каст, а за C style cast надо по рукам бить. Сколько я уже наслышался проблем из-за него.

Хочу услышать. Всем понятно что static_cast - это как бы "показатель грамотности", и я с этим полностью согласен. Однако можете ли Вы привести примеры (и побольше) где static_cast работает корректно, а вот С приведение - нет? Я лично затрудняюсь

Спасибо

[Пантер]

Допустим, С каст игнорирует константность.

const char *const a = new char;
int *b = static_cast <int*> (a); - ошибка
int *c = (int*) (a); - все нормально

[CuteBunny]

Мой пример:

Код

C++ (Qt)
#include <iostream>
 
class A
{
};
 
class B : public A
{
};
 
class C
{
};
 
int main()
{
    B b;
    C c;
    A *pA = 0;
    pA = (A*)&c; //it's ok for compiler
    pA = static_cast<A*>(&c); //it's bad for compiler... well except for the one i got
}
 

Как мне видется нужность static_cast в том, что он проверяет на стадии компиляции является ли объект А объектом Б, т.е. банально проверяется отношение is-a, если А не есть Б, то такое преобразование ошибочно... Поправьте, если ошибаюсь, я еще всё еще чайник:)

[xokc]

Всем понятно что static_cast - это как бы "показатель грамотности", и я с этим полностью согласен.

А вот я с этим совершенно не согласен. Если человек понимает отличие "cast" друг-от друга, то ему никогда этот самый static_cast и не понадобится. Использование"cast" как табу и показателя грамотности - есть абсолютное зло, в стиле "я не знаю ПОЧЕМУ теперь принято в инкременте цикла использовать ++i, а не i++, но (на всякий случай) пишу именно так, поскольку это - "показатель грамотности".

[Akon]

+CuteBunny
Основное достоинство в том, что static_cast не "опускается" до reinterpreta, в то время как С-стайл запросто.

По инкременту - желательно всегда использовать в циклах одну форму, т.е. поступать единообразно. Префиксный предпочтительней, поскольку для некоторых типов (пользовательских) выше быстродействие, связанное с возвратом ссылки а не объекта.

[LisandreL]

Основное достоинство в том, что static_cast не "опускается" до reinterpreta, в то время как С-стайл запросто.

reinterpret - это ещё не вся глубина падения. С-стайл каст делает ещё и const_cast.
И если у reinterpret'а  я запросто могу придумать разумные применения ( ну, например добавление данных при через QByteArray::append ( const char * str, int len ) ), то если вам понадобился const_cast, то почти наверняка у вас (или у используемой вами библиотеки) что-то не так с кодом.

Ну а так по кастам: dynamic_cast и qobject_cast - могут использоваться для проверки типа объекта, если он точно неизвестен.
Static, reinterept и const касты генерируют ошибку времени и в общем-то просто могут уберечь от ошибки в коде.

[DmitryM]

+CuteBunny
Основное достоинство в том, что static_cast не "опускается" до reinterpreta, в то время как С-стайл запросто.

Что делает приведение типов в стиле С: пытается использовать static_cast, если не получается, использует reinterpret_cast. Далее, если нужно, использует const_cast .

Приведение типов в C++

если вам понадобился const_cast, то почти наверняка у вас (или у используемой вами библиотеки) что-то не так с кодом.

Значит с STL что-то не так, т. к. у std::map нет константного operator[].

[Akon]

reinterpret - это ещё не вся глубина падения. С-стайл каст делает ещё и const_cast.

Да, защита от потери константности тоже большое дело.

то если вам понадобился const_cast, то почти наверняка у вас (или у используемой вами библиотеки) что-то не так с кодом

Правильно.

Значит с STL что-то не так, т. к. у std::map нет константного operator[].

У него семантика такая. Для конст. мапа и поиска есть std::map::find().

[Пантер]

Значит с STL что-то не так, т. к. у std::map нет константного operator[].

В новом стандарте есть:
const T & at( const Key& key ) const; (since C++11)

[DmitryM]

В новом стандарте есть:
const T & at( const Key& key ) const; (since C++11)

1. Не все компиляторы поддерживают C++11;
2. Не все компиляторы поддерживают стандартные исключения.

[Пантер]

1. Большинство уже поддерживает.
2. Всегда есть std::map::find, как уже сказали выше.

[DmitryM]

У него семантика такая. Для конст. мапа и поиска есть std::map::find().

find() возвращает итератор, который в случае отсутствия элемента будет container.end();
Проверить наличие элемента в мапе я могу простым count, а вот получить значение через operator[] не могу.
На лицо явная проблема с удобством использования.

Бывают такие структуры данных, которые используют частотные характеристики данных, и меняют свое состояние от каждого запроса на поиск, в этом случае что?
 Запилим mutable и константые методы?

[DmitryM]

1. Большинство уже поддерживает.

gcc-3X не поддерживает, да и сам стандарт не полностью поддерживается компиляторами. Это все привязка к компиляторам и реализациям STL, которую лучше избегать если нужна кроссплатформенность.

[Пантер]

1. Большинство уже поддерживает.

gcc-3X не поддерживает, да и сам стандарт не полностью поддерживается компиляторами. Это все привязка к компиляторам и реализациям STL, которую лучше избегать если нужна кроссплатформенность.

А Qt4 разве собирается с gcc-3Х? Если так завязываться за старое, никакого прогресса не будет.

[LisandreL]

А Qt4 разве собирается с gcc-3Х?

4.5 собиралось. http://www.prog.org.ru/topic_12303_0.html

Значит с STL что-то не так, т. к. у std::map нет константного operator[].

Ну если б с ней было всё так, её б не меняли с приходом нового стандарта.

Проверить наличие элемента в мапе я могу простым count, а вот получить значение через operator[] не могу.

Код

C++ (Qt)
map.find( x )->second

Бывают такие структуры данных, которые используют частотные характеристики данных, и меняют свое состояние от каждого запроса на поиск, в этом случае что?
 Запилим mutable и константые методы?

Ну, если они меняются, то константой они быть не могут (с точки зрения логики, а не возможностей языка).
Хотя ваш вариант сработает.