Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Василий, пример, пожалуйста!
Знаю только один случай, когда необходимо выделять память и нужен указатель на неё.
Уверен, что можно почти всегда обойтись без этого. Желательно не использовать ручное управление памятью. Всегда есть стандартная библиотека, где эти вопросы уже решены.
Наличие динамической идентификации типов обычно говорит о костыльной архитектуре проекта.
Наличие динамической идентификации типов говорит о высокой степени полиморфизма и более высоком уровне абстракции. Повышает управляемость и масштабируемость проекта. Позволяет работать с кодом на уровне интерфейсов и поощряет программиста не вдаваться в подробности реализации.
Василий, по-моему ваш пример оторван от жизни. Есть шаблоны (макросы в мкл), они могут решить массу вопросов на стадии компиляции. А если вам приходится делать понижающее приведение - вы плохо спроектировали программу (об этом даже Страуструп говорил).
Чем понижающее приведение при строгом контроле типов плохо? Страуструп это говорил, когда ни какого контроля типов еще не было и в помине. Сейчас же зная производный тип можно гарантировать преобразование еще до его начала и тем самым избежать ошибок времени выполнения.
А вот плюсы понижающего приведения очевидны. Основной - эта работа на уровне интерфейсов. Если конструктор базового класса закрыт в области protected, то он - интерфейс и абстрактный класс и мы можем работать с ним на его уровне без необходимости знать уточняющую реализацию потомков. Но если мы реализуем полиморфное поведение в зависимости от типа экземпляра, то гарантированно можем уточнить реализацию соответствующего экземпляра и например вызвать только ему присущий метод. С функциями virtual даже приведение типов не потребуется. Ведь виртуальные функции вызовут конкретную реализацию "за кулисами".
... С функциями virtual даже приведение типов не потребуется. Ведь виртуальные функции вызовут конкретную реализацию "за кулисами".
Чем понижающее приведение при строгом контроле типов плохо? ...
Если писать правильно, то этого просто не нужно.
P.S: я не объединяю самапальную идентификацию типов и механизм виртуальных функций в один флакон.
Пример из реального приложения на MQL:
Хотелось бы услышать мнения экспертов, как бы они стали решать подобную задачу. Лично мной она была решена с помощью динамической идентификации типов, паттерна "шаблонный метод" и понижающих преобразований. Решена она была на столько хорошо, что в итоге позволила создавать сложные интерактивные таблицы с нерегулярными, полностью настраиваемыми элементами. Результаты настолько ощутимы, что мне кажется наивным утверждения что де "динамическая идентификация - это костыль", а "понижающее преведение - есть зло".
p.s. Pavlick, Вы кстати так и не ответили, чем же конкретно плохо понижающее приведение.
Что вы, я далеко не эксперт. То что я сказал про понижающее приведение - мой опыт, я стремлюсь писать именно так + это подтверждают уважаемые мной люди. Писать программу чтобы чего-то доказать, мне жалко своего времени.
Pavlick, Вы кстати так и не ответили, чем же конкретно плохо понижающее приведение.
Сложно объяснить. Понимаю, а сказать не могу )). В книгах, наверное, объяснят лучше.
Что вы, я далеко не эксперт.