Кто может раскрыть тайну "всемирного отказа от dynamic_cast" ?

Вроде как трудоемкий каст, т.к. выполняет проверки типов

Он довольно редкий гость. Сложно придумать случай, когда его хочеться применить.

dynamic_cast - это маркер плохого ооп, есть двойная диспетчеризация, визитеры

А если я правильно понимаю - все это делает dynamic_cast, но на стороне компилятора

Как правило, там, где надо делать даункасты, тип и так известен.

Без rtti он не нужен, а rtti вроде отключают для повышения перфоманса

В смысле всемирного отказа? Это не от каких то практик зависит, а от потребностей проекта.

Технически если код использует большое количество dynamic_cast то он плохо спроектирован и дурно пахнет - используйте правильное проектирование интерфейсов. Также dynamic_cast имеет существенные накладные расходы времени исполнения. В режиме -fno-rtti этот оператор не будет компилироваться.

Если фичей может воспользоваться даже дурак, то только дурак ей и будет пользоваться.

Шаблоны это тоже фича только для дураков ?

Существенные накоадные расходы ? - избегая его мы делаем тоже самое, только "хуже"

https://gist.github.com/andreasWallner/9c86a115a5b9fde91d6a

Так а можно какой-то конкретики, какие ошибки могли быть допущены в архитектуре?

Если код выглядит вот так значит скорее всего плохой дизайн: if (auto ptr = dynamic_cast<Pet>(origin)) { … } if (auto ptr = dynamic_cast<Cat>(origing)) { … } if (auto ptr = dynamic_cast<Weapon>(origin))

Или его нет.

Бро сделай через switch&case

Время хороших советов от адептов Си? :)

Та я на плюсах писал ещё когда ты мама говорить не умел

А я думал, Вы уже вымерли... Вместе с прочими динозаврами. Видимо, дураки вечны

Данный код просто на порядок проигрывает в эффективности коду: Origin.QueryIntetface(IID_ICat....) ... и на два порядка коду switch(origin.type) case iiCat: ...

Та ты неук, шо ты меня дураком называешь

И что в нем плохого? Кроме медленного каста

Та вообще пуфик Сделай красивенько тока Типа: 1)🌚👉if… 2)😃🫴🏿if…

Если серьезно, то даже если не брать в учёт всю ту хернь , которая, как я понял, тебе не особо делает погоду, то всё равно быдлокод писать не вариант. Работать-то оно будет, но в таком коде сложнее разобраться…смотреть неприятно. Думаю, ты и сам понимаешь. Крч, суть в том, что это плохая привычка и в будущем, когда над кодом будет работать два+ дядек, то один из дядек может дать в бубен за такое

Зачем спрашивается в язык добавили rtti, если каждый пилит свой?

Потому что язык делают люди, которые совершают ошибки, а ошибка в дизайне лечится очень долго и плохо (если поправить через defect report нельзя). Вон std::regex отвратительный получился, и ничего с ним еще не сделали

std::regex собираются выбросить

Ваш код должен быть полностью выразим через интерфейсы и знать конкретные типы наследников вы не должны в пользовательском коде. Ифать код — последнее дело

Круто, ну вот отличная иллюстрация, 10+ лет на неудачное решение

Закон мерфи.

А это точно не ошибка дизайна?

Да лол почти в любом проекте полно downcast-ов. Это в принципе нормально выдавать интерфейс наружу а внутри работать с имплементацией

Но вот если для него нужен dynamic_cast то да вероятно с кодом не все в порядке.

downcast в имплементации обычно не dynamic_cast

То есть ты хочешь сказать, что если в коде присутствует массив с общим типом, то это код с которым не все в порядке ?

dynamic cast там не нужен

А как тогда работать с этим ?

variant/интерфейс/type erasure контейнеры как std::functuon?

Не всегда можно такое использовать

variant ухудшает читаемость, и лёгкость изменения кода

Используя интерфейсы мы по-прежнему должы использовать dynamic_cast

type erasure внутри себя использует RTTI (typeid)

Да и к тому же - type erasure это "приведение" строго типизированого языка к слабо типизируему - что не есть хорошо

Проблема есть одна со строго типизированными вещами...

И что за она ?

Почему должны?

Реальные компьютеры не работают со строго типизированными программами. Больше проблем нет.

Потому что интерфейс это базовый класс, для работы с которым нам необходимо привести его к его наследнику, а это уже задача dynamic_cast

Ересь вы пишите

Обоснуй

Действительно. Если не приводить интерфейсы один к другому, то и не надо dynamic cast

Это ты обоснуй зачем, имея интерфейс нужен dynamic_cast

Не нужно

x86 не работает со строго типизированным кодом ?

Дорогой zloyka, я разрешаю вам использовать dynamic_cast по поводу и без.

Если те кто реализуют этот интерфейс имеют поля которые не указаны в интерфейсе

Тогда нахрена тебе интерфейс?

Я его и так использую - я просто хочу понять почему есть те, кто выбирает велосипед средствам языка )

Короче, изучай больше с++. Пока ты плаваешь... Причём, это совсем не сложные вещи, не самое непонятное...

А покажи пример, где ты его используешь

Чтобы хранить различные (но схожие) классы в контейнере ?

Они все идиоты и не лечаться. Очевидно же.

А в какой части cpp я плаваю ? )

Значит у них есть общее - интерфейс, и через этот интерфейс мы имеем доступ к поведению, зависящего от конкретной реализации. К чему здесь dynamic_cast?

В ООП.

Мне кажется, этого термина нет в с++.

Ну... Может в стандарте и нет.

https://godbolt.org/#z:OYLghAFBqd5TKALEBjA9gEwKYFFMCWALugE4A0BIEAZgQDbYB2AhgLbYgDkAjF%2BTXRMiAZVQtGIHgBYBQogFUAztgAKAD24AGfgCsp5eiyahUAUgBMAIUtXyKxqiIEh1ZpgDC6egFc2TEAsATnJ3ABkCJmwAOT8AI2xSEAAOcgAHdCViFyYvX39AkIys5yEIqNi2BKTUh2wnHJEiFlIiPL8A4PtsR1KmJpaicpj4xJT7Ztb2gq6lSaHIkaqx5IBKe3QfUlROLgB6PYBqABUATzTsQ9PN0kOMHEOkROxyQ7JD%2BnQWTEPjQ%2Bx1Ow0owAHRmLQAQXBUIsAGZIqhfA8zLCPAA3CQtUgsU4o3DQyzwpiInzI1Fo%2BokUh4gmQxEsJRKQ5WBnYESnObYNhmADsNkhaR8cXoBFQIGhh0lhzRBFaPgk0vQBB%2BPjSmBYRGwEFWvJsPIAIij%2BVCDUbaRD6YzDqokBzRezOWwQIdBcLRczWQ7Ndy%2BdDXSKxRKpWilSq1Rqtas3hTSKRldhdUGpVKABq2dOwqyHACa6esZshyd5hsLUsiREOKdeuczBNNtch0MtTJEmyYmC9XOd/vdLJUnZ9xp7gdLkpDysOqvVmu10cScZwidHycOSjbPwz%2BsOPALEKLpuXc0wIBAGKMsZxKI85bxq/Xu%2BLD8h5cObBYkW1S73UqPJ4pTjIK8%2BzZDlvQAKlvJRQK5JQvxXKUogAd2tW0slQAdP2XZNyCQw5Wx8dsMJ1ZdHwbb9JUEUgIBYHwSDAw44lZAB9KDHWdVjvSUHVfSwssaGo2j0HotJUNFFjoLYQ4US3TBTlYNgxPEOYrxtO10IkiDYVwCBGJUcTHVWbjjXg%2BCRLU/TvQAWjxFMpNhLcAFZdxMlczLQiyuWsrTszsrcgmckzi3%2BegVEOAgaEOAS6LvAjMA8yTpMOWT5MUhkiCvfDCI0vEdOYjiuUMuCXJ/dd4q83A11i3ypL5HhXgsV5YVeaRSOMwKD3IlddOwMq8SnCNPzI/cSxNEauHWehuAc/gAi4HRyHQbgPDzLNKu2S5CT4cgiG0cb1gAaxABytEMbhpBm3aFu4fglBAE6drm8byDgWAUAwNg0gYRJKGod7PsYJJgB4HgmroehNVIW6dMuuJIhaU5uC296OGEAB5Jh6ARx7yBwN8TEkbHCFISkCApW7sYBepaN2Lbyx6S6RTibFSFOLwcEuog4ydXgnpoIxgCUAA1AhsEQ1GLlmrbBGEMQJE4GQ5GEZQ1E0bH9DqowTDQFbDAIOJbsgdZ0DSPpycs1HYRunoSdcCB3GmAI6vCRZKmqAximyIQHfdzJPaYYZXbGOq6gaIQBimbwOgMEO%2BnDhYKlGJJg/mb3k8GAPE6kdY1p2AxOewGmnsmrhppwy7Fq4dRkgANks6vpEOYBUFQbceBBWFIuW/NrFefBiHeTbXi8D6vtuTbVn4B6dEM8hDuO06uHOsvsYrm67u23aZ%2BLix%2BCdHk260avYWSYIeWSHk4WkLRZFm%2BbV43x71he5AQE2IhBSIH6ID%2B0fonYXYq613ro3Zurd278GwIQKkyoDDS1EOISQCs4HKw0JddW5BELYjSIjIuU0Lor24KjWiH83gRUAXXBuTcW7A3bp3dAI8AZSThDwCeD9p7rCeN8MY2oF5LydBYZIIIgiwmrjwHkWgLA8AsDyauDkggOQcsvO%2B117DrynntBelslH8HvuomeMYsiuGkEAA

В каком из трех принципов ООП я плаваю ?

Ну вот это пример плохого дизайна. Читай о визитерах, например и т.п. это немасштабируемое решение. О SOLID почитайте еще

В ООП есть три принципа? Это как три закона Ньютона?

Согласен - визитор здесь будет более выгоден чем dynamic_cast

давай проще. Есть 1 принцип: полиморфизм подтипов. То есть, виртуальные функции с наследованием состояния

... наш преподаватель по теоретической механике говорил "вы незнаете кинематики" всякий раз, когда студент начинал нести какую-то пургу. Полиморфизм вообще не является образующей особенностью ООП.

является, в этом его суть