ООП, шаблоны и макросы в mql5, тонкости и приёмы использования - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Насчёт многопроходности - поторопился, наивно думал, что мкл разрешит это
Ну вот я с этого и начинал разговор тут. Планировал тоже заменять все статики на глобалы (хоть это и жесть конечно). Но как показано выше, с шаблонами такое не прокатит. С макросами тоже. А я всё это широко применяю. Поэтому и сделал свою реализацию. Хотя она конечно не решает всех проблем. Динамические массивы по-прежнему нельзя инициализировать, константные типы тоже. Поэтому их однозначно придётся выносить на глобальный уровень
Я тоже широко использую шаблоны и макросы, но при этом рассматриваю свободные функции, только как вспомогательные (и в принципе вообще нежелательные) элементы архитектуры. Когда вся реализация упакована внутрь объектов, а статики объявляются только на уровне класса, раздражающие косяки появляются разве что с тем, что иногда сложно понять логику правильной последовательности их объявления, чтобы компилятор не ругался...
Так здесь переменные. А вот с функциями - да, многопроходно получается, так что всё верно было сказано. Проблема же возникает именно из-за порядка инициализации функций. Короче, в C++ единый строгий порядок, относящийся и переменным, и функциям, и к типам. А в MQL всё вразнобой.
Многопроходность это плохо в любом случае - нарваться на рекурсию, deadlock и т.п. Но ведь в плюсах можно forward declaration сделать. Поэтому только с умом, осторожно (явнями forward declaration), и не так как сейчас у многопроходного компилятора - будто для любой функции сделана forward declaration, рано или поздно эти грабли ударят по лбу.
Многопроходность это плохо в любом случае - нарваться на рекурсию, deadlock и т.п. Но ведь в плюсах можно forward declaration сделать. Поэтому только с умом, осторожно, и не так как сейчас у многопроходного компилятора - будто для любой функции сделана forward declaration, рано или поздно эти грабли ударят по лбу.
Согласен. Чуть ранее эту тему как-раз обсуждали. Здесь многим именно это нравится в языке, что можно на заморачиваться с порядком объявления функций. Да чего греха таить, меня и самого когда-то радовало это ) А в плюсах раздражала его занудность. Но с опытом приходит понимание.
Я тоже широко использую шаблоны и макросы, но при этом рассматриваю свободные функции, только как вспомогательные (и в принципе вообще нежелательные) элементы архитектуры. Когда вся реализация упакована внутрь объектов, а статики объявляются только на уровне класса, раздражающие косяки появляются разве что с тем, что иногда сложно понять логику правильной последовательности их объявления, чтобы компилятор не ругался...
Соглашусь, если всё чётко выстроено в ООП, тогда не только свободные функции не нужны, но и шаблонные методы тоже.
Шаблонные методы нужны везде, где не хочется писать кучу повторяющегося кода, хоть ООП хоть не ООП. Свободные функции это другое дело - это уже разные стили программирования.
Шаблонные методы нужны везде, где не хочется писать кучу повторяющегося кода, хоть ООП хоть не ООП
В ООП для этого придуманы интерфейсы.
Интерфейсы все таки немного для другого. Если я хочу, чтобы у меня 1 и тот же код выполнял одинаковую работу с разными типами в зависимости от класса параметра (без объявления доп классов), интерфейс не поможет.
Интерфейсы все таки немного для другого. Если я хочу, чтобы у меня 1 и тот же код выполнял одинаковую работу с разными типами в зависимости от класса параметра (без объявления доп классов), интерфейс не поможет.
Если параметры разных типов, то логично сделать несколько перегруженных методов с соответствующими типами. Вам же всё-равно придётся их в функции как-то разделять. Так лучше разбить на отдельные функции, чем городить портянку, которая к тому же принимает безликий тип, т.е. можно по ошибке передать в неё всё что угодно и получить ошибку компиляции внутри библиотеки, что не есть гуд. А может даже и не получить, что не гуд вдвойне )
Короче, в полноценном ООП шаблонные функции - это костыль (за редким исключением)
Короче, в полноценном ООП шаблонные функции - это костыль.
Вот и приехали
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Особенности языка mql5, тонкости и приёмы работы
Alexey Navoykov, 2019.01.25 10:11
Ну вот я с этого и начинал разговор тут. Планировал тоже заменять все статики на глобалы (хоть это и жесть конечно). Но как показано выше, с шаблонами такое не прокатит. С макросами тоже. А я всё это широко применяю. Поэтому и сделал свою реализацию. Хотя она конечно не решает всех проблем. Динамические массивы по-прежнему нельзя инициализировать, константные типы тоже. Поэтому их однозначно придётся выносить на глобальный уровень.