Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вот и приехали
Вот как мы поступим.
Если static переменная инициализируется константой, то эта инициализация будет происходить на этапе глобальной инициализации, как и раньше
Иначе (инициализация вызовом или переменной), static переменная будет инициализироваться при первом обращении (будет как в C++), само такое обращение будет завёрнуто в условие с неявной глобальной переменной/флагом, например
для MQL кода:
Будет сгенерирован следующий псевдокод
Вам же всё-равно придётся их в функции как-то разделять.
Совсем даже не обязательно и не всегда. Примеры приводить не буду, чтобы не замусоривать ветку.
Вот как мы поступим.
Да, примерно так. Ибо в MQL нет полноценного ООП. Плюс куча багов, о которых я регулярно рапортую, но безуспешно. А против багов приходится обороняться костылями, что поделаешь.
Что-то вы меня совсем запутали. Если в ... читайте свои слова
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Особенности языка mql5, тонкости и приёмы работы
Alexey Navoykov, 2019.01.25 11:44
Если параметры разных типов, то логично сделать несколько перегруженных методов с соответствующими типами. Вам же всё-равно придётся их в функции как-то разделять. Так лучше разбить на отдельные функции, чем городить портянку, которая к тому же принимает безликий тип, т.е. можно по ошибке передать в неё всё что угодно и получить ошибку компиляции внутри библиотеки, что не есть гуд. А может даже и не получить, что не гуд вдвойне )
Короче, в полноценном ООП шаблонные функции - это костыль (за редким исключением)
В MQL все хорошо с ООП, если множественное наследование добавят (для интерфейсов хотя бы, а то они совсем бесполезны в нынешнем виде), то будет вообще идеально.
Так интерфейсы - это основа нормального ООП. А вы при этом говорите, что в MQL всё хорошо.
Так интерфейсы - это основа нормального ООП. А вы при этом говорите, что в MQL всё хорошо.
Основа нормального ООП - это полиморфизм, а не интерфейсы. Интерфейсы - это основа определенной структуры классов. Вообще я бы с удовольствием поговорил на эти темы но боюсь что данная ветка не для этого.
Основа нормального ООП - это полиморфизм, а не интерфейсы. Интерфейсы - это основа определенной структуры классов. Вообще я бы с удовольствием поговорил на эти темы но боюсь что данная ветка не для этого.
Ну почему же, ветка вполне подходящая. Мы ж обсуждаем особенности языка MQL, а отсутствие множественного наследования - это вполне себе особенность )
Ок, основа конечно полиморфизм, но без раздельных интерфейсов - он не удобен в применении. Это зачастую и приводит к тому, что объекты приходится передавать как шаблонные аргументы, а не как интерфейсы.
Я вот тут описывал свой вариант имитации множественных интерфейсов. Соответственно класс у меня может объявляться так:
Ну почему же, ветка вполне подходящая. Мы ж обсуждаем особенности языка MQL, а отсутствие множественного наследования - это вполне себе особенность )
Ок, основа конечно полиморфизм, но без раздельных интерфейсов - он не удобен в применении. Это зачастую и приводит к тому, что объекты приходится передавать как шаблонные аргументы, а не как интерфейсы.
Я вот тут описывал свой вариант имитации множественных интерфейсов. Соответственно класс у меня может объявляться так:
По-моему, не все так уж плохо. Не так уж много базовых основных интерфейсов в том же С#, по-моему (я не спец по С#), чтобы их методы нельзя было свести к одному базовому суперклассу, а потом наследовать кому что нужно.
П.С. Через конструкции типа <<<<>>>> реализовывать что-то множественное имхо это как-то через одно место. Лучше уж функции делать через операторы например а==b вызывает a.compareto( b ), a[comparer]==b вызывает comparer.compare(a,b) и т.п.