Вопрос:
Почему нужно избегать использования <dynamic_cast>?
Чем использования <dynamic_cast> плохо?

Что вы по этому думаете.
Спасибо

Здравствуйте, ilya_ny, Вы писали:

_>Вопрос:
_>Почему нужно избегать использования <dynamic_cast>?
_>Чем использования <dynamic_cast> плохо?

_>Что вы по этому думаете.
_>Спасибо


dynamic_cast использует RTTI и нарушает полиморфизм.
А вообще, ничего плохого, используй наздоровье...

теряется производительность

Здравствуйте, ilya_ny, Вы писали:

_>Вопрос:
_>Почему нужно избегать использования <dynamic_cast>?
_>Чем использования <dynamic_cast> плохо?

_>Что вы по этому думаете.
_>Спасибо

Избегать не нужно, нужно использовать по назначению.
Хотя чрезмерное его применение зачастую означает кривой дизайн.

Здравствуйте, rus blood, Вы писали:


RB>dynamic_cast использует RTTI и нарушает полиморфизм.
объясни пожалуйста

Здравствуйте, maq, Вы писали:

maq>Избегать не нужно, нужно использовать по назначению.
maq>Хотя чрезмерное его применение зачастую означает кривой дизайн.
почему ?

Здравствуйте, ilya_ny, Вы писали:

_>Вопрос:
_>Почему нужно избегать использования <dynamic_cast>?
_>Чем использования <dynamic_cast> плохо?

_>Что вы по этому думаете.
_>Спасибо

Кое-что можно найти здесь

Автор(ы): Robert Schmidt
Дата: 30.09.2002

.
В частности,

Если (предположительно) производная сущность в действительности не является объектом производного типа, то dynamic_cast либо вернет NULL (при преобразовании указателей), либо выбросит исключение (при преобразовании ссылок).

Здравствуйте, ilya_ny, Вы писали:

_>Вопрос:
_>Почему нужно избегать использования <dynamic_cast>?
_>Чем использования <dynamic_cast> плохо?

Это не 100% плохо, а как правило плохо. Т.к. вместо этого нужно использовать полиморфизм. Иначе создается излишнее зацепление на типы Foo и Bar
Т.е. вместо кода

if (Foo* foo=dynamic_cast<Foo*>(a))
{

}
else
if (Bar* bar=dynamic_cast<Bar*>(a))
{

}

нужно использовать

a->virtualFunction();

Для того чтобы понять чем это лучше подумай что будет если ты добавишь еще пару типов. В этом случае тебе придется повыцеплять все if-ы в 100 местах программы, а при использовании полиморфизма ты просто напишешь еще 2 реализации класса.(Возможно кода будет столько же, но во втором случае это не модификация существующего, а добавление нового, соответственно меньше шансов что нибудь сломать)

Более подробно можно почитать вот здесь
http://anatolix.naumen.ru/oop.pdf

RB>>dynamic_cast использует RTTI и нарушает полиморфизм.
_>объясни пожалуйста

RTTI позволяет узнать тип объекта, dynamic_cast — преобразовать к производному классу.
И вызывать его методы напрямую, не используя полиморфизм.

Здравствуйте, ilya_ny, Вы писали:

_>Здравствуйте, maq, Вы писали:

maq>>Избегать не нужно, нужно использовать по назначению.
maq>>Хотя чрезмерное его применение зачастую означает кривой дизайн.
_>почему ?

Потому что пользователю классов придется знать слишком много об иерархии классов.

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

Не знаю насколько удачный пример, но представь, что тебе
для включения ТВ постоянно приходилось бы открывать крышку
и соединять какие-то два проводка. Будет работать? Да, будет работать!
Удобно? Скорей всего нет...

Здравствуйте, ilya_ny, Вы писали:

_>Вопрос:
_>Почему нужно избегать использования <dynamic_cast>?
_>Чем использования <dynamic_cast> плохо?

Как и любое другое приведение типов, не безопасно. Вот пример:

struct A
{
    virtual void FuncA() {}
};
struct B : public A
{
    virtual void FuncA() {}
    virtual void FuncB() {}
};

void main()
{
    A* a = new A();
    a->FuncA();
    
    B* b = dynamic_cast<B*>(a);
    b->FuncA();
    b->FuncB();
}

Здравствуйте, Azir, Вы писали:

A>Здравствуйте, ilya_ny, Вы писали:

_>>Вопрос:
_>>Почему нужно избегать использования <dynamic_cast>?
_>>Чем использования <dynamic_cast> плохо?

A>Как и любое другое приведение типов, не безопасно. Вот пример:

А чем? Если a не сможет быть приведен к B*, то dynamic_cast вернет 0. Главное учесть это в коде и все.

Здравствуйте, rus blood, Вы писали:

RB>И вызывать его методы напрямую, не используя полиморфизм.
Да ну? Если функция виртуальная то и вызываться она будет как виртуальная.

Здравствуйте, Анатолий Широков, Вы писали:

АШ>А чем? Если a не сможет быть приведен к B*, то dynamic_cast вернет 0. Главное учесть это в коде и все.
Оказывается, здесь у меня пробелы в образовании, спасибо за просвещение.

Здравствуйте, ilya_ny, Вы писали:

_>Вопрос:
_>Почему нужно избегать использования <dynamic_cast>?
_>Чем использования <dynamic_cast> плохо?

Почему плохо? Завист от того, где испоьзовать.
Спички — это тоже плохо, но иногда необходимо

_>Что вы по этому думаете.
_>Спасибо

Иногда логика программы может быть построен на dynamic_cast'е как способе получения интерфейса.
Это один из способов построения гибкой эволюционной системы и ничего плохого в этом нет.
Другое дело что dynamic_cast можно использовать для получения конкретного класса, это уже действительно может быть признаком плохого дизайна, но совсем не обязятельно.

Здравствуйте, Anatolix, Вы писали:

A>Здравствуйте, ilya_ny, Вы писали:

_>>Вопрос:
_>>Почему нужно избегать использования <dynamic_cast>?
_>>Чем использования <dynamic_cast> плохо?

A>Это не 100% плохо, а как правило плохо. Т.к. вместо этого нужно использовать полиморфизм. Иначе создается излишнее зацепление на типы Foo и Bar
A>Т.е. вместо кода
[skipped]

Не всегда возможно.

Пример на вскидку (не идеальный)

Например твоя система создает обьект (некоторое событие). Допустим у тебя есть некто, кто с этими событиями работает.
Все хорошо пока у тебя не появляется еще один клиент событий, которому требуется расширенный интерфейс события.
Тогда на выручку приходит dcast. Ты реализуешь в событии, предназаначеном для этого клиента, еще и расширенный интерфейс, а получает его клиент именно через dcast.

A>Более подробно можно почитать вот здесь
A>http://anatolix.naumen.ru/oop.pdf
мммм, лучше ....

(метрики) http://www.objectmentor.com/resources/articles/oodmetrc.pdf
(ISP) http://www.objectmentor.com/resources/articles/isp.pdf

здесь достаточно хорошо показанно зачем не нужно использовать dynamic_cast
(OCP) http://www.objectmentor.com/resources/articles/ocp.pdf

а здесь зачем он может понадобится
(Visitor) http://www.objectmentor.com/resources/articles/acv.pdf
http://www.objectmentor.com/resources/articles/dih.pdf

Здравствуйте, maq, Вы писали:

maq>Здравствуйте, ilya_ny, Вы писали:

_>>Вопрос:
_>>Почему нужно избегать использования <dynamic_cast>?
_>>Чем использования <dynamic_cast> плохо?

_>>Что вы по этому думаете.
_>>Спасибо

maq>Избегать не нужно, нужно использовать по назначению.
maq>Хотя чрезмерное его применение зачастую означает кривой дизайн.

Скажем, если приходится делать выбор между идентификатором класса и dynamic_cast<>, то лучше ессно использовать dynamic_cast<>. IMHO — безопаснее.

Здравствуйте, Alexey Chen, Вы писали:

AC>Пример на вскидку (не идеальный)

Вот ещё пример, то же не идеальный, но вполне реальный

void hero::collision(creature *obj)
{
    if((monster *mstr = dynamic_cast<monster*>(obj)) != 0)
    {
        die_from(mstr);
    }
    else if((apple *apl = dynamic_cast<apple*>(obj)) != 0)
    {
        eat(apl);
    }
    else if((my_friend *frnd = dynamic_cast<my_friend*>(obj)) != 0)
    {
        salute(frnd);
    }
}

RB>И вызывать его методы напрямую, не используя полиморфизм.
Нельзя ли поподробнее, желательно с примером?

_>Почему нужно избегать использования <dynamic_cast>?
"Почему нужно избегать использования молотка? Потому, что если системный блок построен на гвоздях — это признак плохого дизайна."
Dynamic_cast — это инструмент. Как и любой инструмент, он может быть применен неправильно или не там. Инструмент, кроме того, дорогостоящий. Но это совершенно не значит, что его использования следует избегать.

_>Чем использования <dynamic_cast> плохо?
Ничем.