Ошибки, баги, вопросы - страница 2564
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
?
странная ситуация, со стаитиками давно работает все вне класса. а я тут распинаюсь.... ради прикола воспроизведите у себя код:
Вы видите экземпляр объекта? ... а он есть в MQL ;)
ЗЫ: причем есть на уровне справки... ко мне какие претензии?
https://www.mql5.com/ru/docs/basis/oop/staticmembers
К статикам применимы все те же правила (private, protected, public), просто они не требуют создания объекта.
В общем случае нет: например публичный статик нельзя ограничить в производном классе
хм... как бы обьяснить абсурдность ситуации... Вы чего меня квотите в очередной раз? я предложил Вам ознакомиться с сообщениями админов (разработчиков), я показал справку которую они написали, Вы от меня чего хотите своими картинками?
я не размышляю почему оно так, читаю форум и справку и делаю как рекомендуют разработчики. Считаете нужным ну напишите в "комитет по защите стандартов С++", в ООН... ну хотя бы админу в ЛС, если слабо, но тогда заквотьте сообщения разработчиков и добейтесь своего!
ЗЫ: у меня как то получается вставлять исходники, а не картинки, почему у вас так не получилось?
2019.09.17 22:11:49.534 tst (EURUSD,H1) 1:print
2019.09.17 22:11:49.535 tst (EURUSD,H1) 2:print
2019.09.17 22:11:49.535 tst (EURUSD,H1) 3:print
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 2
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 3
2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 4
В коде ошибка только в доступе к private-методу. Этот баг появился недавно.
Функция ChartOpen всегда возращает 0 в сервисе. Хотя сам график открывает.
В коде ошибка только в доступе к private-методу. Этот баг появился недавно.
думал я что то забыл, вот перечитал как в C# статики себя ведут https://metanit.com/sharp/tutorial/3.6.php
Статические члены класса являются общими для всех объектов этого класса, поэтому к ним надо обращаться по имени класса:
Следует учитывать, что статические методы могут обращаться только к статическим членам класса. Обращаться к нестатическим методам, полям, свойствам внутри статического метода мы не можем.
а в MQL статики инициализируются до запуска OnInit() , теперь обсуждаем глобальную видимость приват методов у статиков.... ну такое поведение статиков в MQL - если используем статики, значит не пользуемся возможностями защиты данных в классе, имхо
и насколько это баг? - да как повернут разработчики так и будет, я же пишу, что поведение при использовании операции контекста определяет программист ( оператор разрешения контекста — является оператором с самым высоким приоритетом в языке! ), а насколько компилятор сумеет правильно помочь ну как получится )))
вот так работает?
в целом задачи выполняет
PS: обновился на 2145 - код со статиками ведет себя так же, ну если в таком виде побудет с полгода, окажется что это запланированное поведение статиков ;)
UPD: вспомнл как на сленге это все называется - грязные приемы! ))) - поискать их много примеров в сети, где то это поведение как стандарт языка воспринимается, а где то привязано к конкретным компиляторам от производителя. В Питоне же eval() по сути полностью рушит линейное выполнение кода? - ну кто то юзает, кто то пишет не юзать, т.к. поведение непредсказуемое
UPD: проверил на 2145 свой вопрос заданный месяц назад https://www.mql5.com/ru/forum/320733#comment_12989063
https://www.mql5.com/ru/forum/320733#comment_12958594
ничего не изменилось, на bool при проверке типов компилятор так не научился писать предупреждения - вот это вот очень не приятно, уже искал у себя ошибку в коде, хотя была уверенность, что компилятор MQL всегда строго следит за соответствием типов
и насколько это баг? - да как повернут разработчики так и будет
Очевидно же, что баг исправят.
ничего не изменилось, на bool при проверке типов компилятор так не научился писать предупреждения
Автоматический кастинг указателей и числовых типов в bool - это очень удобно.
ничего не изменилось, на bool при проверке типов компилятор так не научился писать предупреждения - вот это вот очень не приятно, уже искал у себя ошибку в коде, хотя была уверенность, что компилятор MQL всегда строго следит за соответствием типов
При данном кастинге нет потери данных. Либо 0, либо не 0.
Другое дело, когда имеет место кастинг double -> любой целочисленный тип (до int32 включительно)
При данном кастинге нет потери данных. Либо 0, либо не 0.
Другое дело, когда имеет место кастинг double -> любой целочисленный тип (до int32 включительно)
а наоборот?
я искал у себя баг уже в коде
сначала написал тест, но использовал сначала int , потом отказался в сторону bool, но исправил не весь код, уже не помню, но примерно так:
я к такому поведению как бы готов сейчас, но почему пишу об этом...ну в проверке условий MQL в if() - жестко типы контролирует? любое использование не булевых операций выдает же предупреждение? - ну и как писал в том же C# в VS2017 - мой код примера не будет скомпилирован, а MQL не выдает предупреждений. По моему для новичков в программировании под MQL такое поведение таит некие сюрпризы.
Очевидно же, что баг исправят.
спорить не буду, но свое мнение, что закладываться на контроль от компилятора при выходе за пределы класса через статики как и использование оператора разрешения контекста - не стоит ,
т.е. если написал static метод/поле или применил :: - на компилятор не надейся