1. повторяю вызов SymbolInfoDouble(_Symbol,SYMBOL_VOLUME_STEP) - ибо не оговорен порядок инициализации, т.е. не факт, что у меня будет сначала инициализирована VolumeSTEP , а лишь затем уже будет вызван GetDigitsInVolumeStep()
2. хотелось бы избавиться от использования статического метода static int GetDigitsInVolumeStep() - насмотрелся видео на ютубе, что в чистом ООП не гоже использовать статические методы, вот борюсь с ветряными мельницами
1. повторяю вызов SymbolInfoDouble(_Symbol,SYMBOL_VOLUME_STEP) - ибо не оговорен порядок инициализации, т.е. не факт, что у меня будет сначала инициализирована VolumeSTEP , а лишь затем уже будет вызван GetDigitsInVolumeStep()
1. т.е. боитесь, что порядок инициализации статиков неопределён? Вообще это не так, в плюсах инициализация в порядке определения в коде. Так что не парьтесь, сначала VolumeSTEP, а затем VolumeDIGITS.
1. т.е. боитесь, что порядок инициализации статиков неопределён? Вообще это не так, в плюсах инициализация в порядке определения в коде. Так что не парьтесь, сначала VolumeSTEP, а затем VolumeDIGITS.
да, не то что боюсь, скажем предохраняюсь, я считаю,что код должен иметь хоть какую гарантию от изменения поведения компиляции - в общем ДА
ЗЫ: тут в общем почему топик который раз апаю за день - хочу увидеть насколько реально сделать что то как в видео автор Егор рассказывает, пока сомневаюсь, что получится что то эффективное - сейчас вот уже и статик методы использую, да и с инициализацией уже некие сомнения появились
1. т.е. боитесь, что порядок инициализации статиков неопределён? Вообще это не так, в плюсах инициализация в порядке определения в коде. Так что не парьтесь, сначала VolumeSTEP, а затем VolumeDIGITS.
Члены класса могут быть объявлены с использованием модификатора класса памяти static. Такие члены данных разделяются всеми экземплярами данного класса и хранятся в одном месте. Нестатические члены данных создаются для каждой переменной-объекта класса. Отсутствие возможности объявлять статически члены класса привело бы к необходимости объявлять...
да, не то что боюсь, скажем предохраняюсь, я считаю,что код должен иметь хоть какую гарантию от изменения поведения компиляции - в общем ДА
ЗЫ: тут в общем почему топик который раз апаю за день - хочу увидеть насколько реально сделать что то как в видео автор Егор рассказывает, пока сомневаюсь, что получится что то эффективное - сейчас вот уже и статик методы использую, да и с инициализацией уже некие сомнения появились
спс, немного не ту цель ставлю, так я могу сделать
тут в общем что хочу добиться:
1. класс CDeal - самостоятельный, он открывает/закрывает/сопровождает свой ордер по одной стратегии - стратегии это перечисление, чтобы в оптимизаторе прокрутить микс стратегий
2. исходя из пп №1 получается, что мне не нужно больше нигде иметь переменные окружения терминала SYMBOL_VOLUME_MAX, SYMBOL_VOLUME_MIN, SYMBOL_VOLUME_STEP и кол-во знаков в SYMBOL_VOLUME_STEP - это не изменяется в ходе работы MQL-программы
3. исходя из пп №1 и №2 - я могу инкапсулировать методы открытия/закрытия/трейлинга ордера и сами свойства ордера в один класс CDeal - я же нигде в дальнейшем не собираюсь использовать все это? - значит могу все в один класс обернуть
пп 1-3 все решаемо, НО.. ОК, вот со статиками помогли, пусть так ибо есть справка, хоть чем то свое решение можно обосновать, теперь код такой:
т.е. сейчас нет участков повторяющегося кода (вызовов) - это эффективный код, НО как уйти от использования статической функции static int Cdeal::GetDigitsInVolumeStep() - по сюжету видео, автор считает что возможно без статических функций писать код ООП, я пока вижу, что это мало того, что неудобно, так и не всегда это все и возможно использовать, про методы Get и Set - скорее всего обойдусь без них, дальше видно будет
Vladimir Simakov: Вариант со static полем имеет один огромный минус. Вы не сможете иметь разные значения этого поля в разных экземплярах этого класса.
да, спс, я знаю это, задача как раз и получить эффективный код без лишних переменных и лишнего использования памяти
пока остался не решенный вопрос: как уйти от использования статической функции static int Cdeal::GetDigitsInVolumeStep()
вот набросал свой класс, который должен один раз инициализировать поля константными значениями, кажется все работает как задумано:
Это чисто тестовый класс или реально собираетесь его использовать?
Если второе, то так делать не стоит. Статические переменные не переинициализируются при смене символа, насколько я помню.
Да и вообще, иницилизировать константые статики некими внешними значениями, которые не факт что будут доступны на момент инициализации - не лучшая идея.
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
Статическая переменная, она и без наследования будет одна на все экземпляры.
проверил, ну да! все проще оказалось!
2019.08.29 15:14:09.847 tst__ EURUSD,M15: initialized
2019.08.29 15:14:09.847 tst__ EURUSD,M15: B::Bru
2019.08.29 15:14:09.847 tst__ EURUSD,M15: B::Bru
2019.08.29 15:14:09.847 tst__ EURUSD,M15: B::Bru
2019.08.29 15:14:09.847 tst__ EURUSD,M15: B::Bru
2019.08.29 15:14:09.847 tst__ EURUSD,M15: B::Bru
2019.08.29 15:14:09.847 tst__ EURUSD,M15: MyTerminalInfoString
вижу, что переменную Language всего один раз инициализировал, т.е. это более простое решение
Спасибо!
Подскажите, чем отличается ?
Создание объекта, или указателя, таким образом
от классического создания
Отличается тем, что в 1ом случае в C++ идентификатор класса CClass указывать необязательно
вот набросал свой класс, который должен один раз инициализировать поля константными значениями, кажется все работает как задумано:
не нравятся мне 2 момента:
1. повторяю вызов SymbolInfoDouble(_Symbol,SYMBOL_VOLUME_STEP) - ибо не оговорен порядок инициализации, т.е. не факт, что у меня будет сначала инициализирована VolumeSTEP , а лишь затем уже будет вызван GetDigitsInVolumeStep()
2. хотелось бы избавиться от использования статического метода static int GetDigitsInVolumeStep() - насмотрелся видео на ютубе, что в чистом ООП не гоже использовать статические методы, вот борюсь с ветряными мельницами
ссылки на видео, он одинаковы по сути https://youtu.be/lfdAwl3-X_c и https://youtu.be/zME4SOCHT0I
как бы вот эти 2 момента, которые мне не нравятся по другому переписать ?
1. повторяю вызов SymbolInfoDouble(_Symbol,SYMBOL_VOLUME_STEP) - ибо не оговорен порядок инициализации, т.е. не факт, что у меня будет сначала инициализирована VolumeSTEP , а лишь затем уже будет вызван GetDigitsInVolumeStep()
1. т.е. боитесь, что порядок инициализации статиков неопределён? Вообще это не так, в плюсах инициализация в порядке определения в коде. Так что не парьтесь, сначала VolumeSTEP, а затем VolumeDIGITS.
1. т.е. боитесь, что порядок инициализации статиков неопределён? Вообще это не так, в плюсах инициализация в порядке определения в коде. Так что не парьтесь, сначала VolumeSTEP, а затем VolumeDIGITS.
да, не то что боюсь, скажем предохраняюсь, я считаю,что код должен иметь хоть какую гарантию от изменения поведения компиляции - в общем ДА
ЗЫ: тут в общем почему топик который раз апаю за день - хочу увидеть насколько реально сделать что то как в видео автор Егор рассказывает, пока сомневаюсь, что получится что то эффективное - сейчас вот уже и статик методы использую, да и с инициализацией уже некие сомнения появились
1. т.е. боитесь, что порядок инициализации статиков неопределён? Вообще это не так, в плюсах инициализация в порядке определения в коде. Так что не парьтесь, сначала VolumeSTEP, а затем VolumeDIGITS.
В MQL тоже
https://www.mql5.com/ru/docs/basis/oop/staticmembers
да, не то что боюсь, скажем предохраняюсь, я считаю,что код должен иметь хоть какую гарантию от изменения поведения компиляции - в общем ДА
ЗЫ: тут в общем почему топик который раз апаю за день - хочу увидеть насколько реально сделать что то как в видео автор Егор рассказывает, пока сомневаюсь, что получится что то эффективное - сейчас вот уже и статик методы использую, да и с инициализацией уже некие сомнения появились
Пользоваться как-то так:
А в коде так:
Пользоваться как-то так:
А в коде так:
спс, немного не ту цель ставлю, так я могу сделать
тут в общем что хочу добиться:
1. класс CDeal - самостоятельный, он открывает/закрывает/сопровождает свой ордер по одной стратегии - стратегии это перечисление, чтобы в оптимизаторе прокрутить микс стратегий
2. исходя из пп №1 получается, что мне не нужно больше нигде иметь переменные окружения терминала SYMBOL_VOLUME_MAX, SYMBOL_VOLUME_MIN, SYMBOL_VOLUME_STEP и кол-во знаков в SYMBOL_VOLUME_STEP - это не изменяется в ходе работы MQL-программы
3. исходя из пп №1 и №2 - я могу инкапсулировать методы открытия/закрытия/трейлинга ордера и сами свойства ордера в один класс CDeal - я же нигде в дальнейшем не собираюсь использовать все это? - значит могу все в один класс обернуть
пп 1-3 все решаемо, НО.. ОК, вот со статиками помогли, пусть так ибо есть справка, хоть чем то свое решение можно обосновать, теперь код такой:
создал 3 экземпляра Cdeal, получил в логе:
2019.08.29 21:53:53.613 AnyGrid_v1.00 EURUSD,M30: initialized
2019.08.29 21:53:53.613 AnyGrid_v1.00 EURUSD,M30: Cdeal::CdealVolumeMAX = 100000.0 , VolumeMIN = 0.01 , VolumeSTEP = 0.01 , VolumeDIGITS = 2
2019.08.29 21:53:53.613 AnyGrid_v1.00 EURUSD,M30: Cdeal::CdealVolumeMAX = 100000.0 , VolumeMIN = 0.01 , VolumeSTEP = 0.01 , VolumeDIGITS = 2
2019.08.29 21:53:53.613 AnyGrid_v1.00 EURUSD,M30: Cdeal::CdealVolumeMAX = 100000.0 , VolumeMIN = 0.01 , VolumeSTEP = 0.01 , VolumeDIGITS = 2
2019.08.29 21:53:53.613 AnyGrid_v1.00 EURUSD,M30: Cdeal::GetDigitsInVolumeStep
пока все работает как и задумано!
т.е. сейчас нет участков повторяющегося кода (вызовов) - это эффективный код, НО как уйти от использования статической функции static int Cdeal::GetDigitsInVolumeStep() - по сюжету видео, автор считает что возможно без статических функций писать код ООП, я пока вижу, что это мало того, что неудобно, так и не всегда это все и возможно использовать, про методы Get и Set - скорее всего обойдусь без них, дальше видно будет
Вариант со static полем имеет один огромный минус. Вы не сможете иметь разные значения этого поля в разных экземплярах этого класса.
да, спс, я знаю это, задача как раз и получить эффективный код без лишних переменных и лишнего использования памяти
пока остался не решенный вопрос: как уйти от использования статической функции static int Cdeal::GetDigitsInVolumeStep()
вот набросал свой класс, который должен один раз инициализировать поля константными значениями, кажется все работает как задумано: