Бета-версия платформы MetaTrader 5 build 1625: Пользовательские финансовые инструменты - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вопрос по DEAL_REASON_SL.
В OnInit DEAL_REASON_SL имеет значение 9
а в OnTradeTransaction при срабатывании Stop Loss DEAL_REASON HistoryDealGetInteger:
deal_reason=HistoryDealGetInteger(trans.deal,DEAL_REASON);
возвращает уже значение 4
Полный код:
При тестировании происходит Crash:
Windows 7 x64, повторяемость на двух машинах. Компиляция советника с оптимизацией и без оптимизации.
Вопрос по DEAL_REASON_SL.
В OnInit DEAL_REASON_SL имеет значение 9
а в OnTradeTransaction при срабатывании Stop Loss DEAL_REASON HistoryDealGetInteger:
возвращает уже значение 4
Полный код:
На числовые значения кодов лучше не закладываться
На числовые значения кодов лучше не закладываться
Там явная ошибка
Результат: DEAL_REASON_SL==DEAL_REASON_SL ? falseНа числовые значения кодов лучше не закладываться
Так проверку по числовому значению ввёл в пример, чтобы понять, почему после Stopp loss нет захода в
и оказалось, что DEAL_REASON_SL имеет значение '9', но вот внутри OnTradeTransaction()
HistoryDealGetInteger(trans.deal,DEAL_REASON);
возвращает '4', а должно возвращать '9'.
Так проверку по числовому значению ввёл в пример, чтобы понять, почему после Stopp loss нет захода в
и оказалось, что DEAL_REASON_SL имеет значение '9', но вот внутри OnTradeTransaction()
возвращает '4', а должно возвращать '9'.
Причину нашли и исправили, спасибо за сообщение!
Не пользователь, а программист.
У программиста очень много возможностей где угодно сохранить указатели на убитые объекты. Поэтому он сам должен полностью отдавать себе отчет в использовании ссылок.
Сам язык в обязательном порядке проверяет все указатели перед использованием и выдает критическую ошибку при попытке обращения к ранее удаленным объектам.
Если у вас хватает смелости копировать сложные объекты без своего оператора копирования, то это исключительно ваш риск. При этом, если что пойдет не так, среда исполнения остановит программу.
Нет, в данном контексте не программист, а именно пользователь класса. Вы видимо рассуждаете с позиции структурно-процедурного программиста, самостоятельно контролирующего всё и вся, досконально знающего внутреннюю реализацию всех объектов, с которыми он работает.
Я веду речь об объектно-ориентированном подходе. Одним из основополагающих принципов тут является инкапсуляция, если вам знакомо это понятие. В рамках этой парадигмы конкретная реализация любого объекта скрыта от посторонних глаз и является исключительно внутренним делом этого объекта. А пользователь довольствуется тем функционалом, который предоставляет этот объект с помощью публичных методов. Внутренности нас вообще не касаются. Тем более что реализацию этих внутренностей возможно программировал другой человек. В общем странно, что я тут вынужден объяснять эти азы, хотя казалось бы, вы должны быть знакомы с ними не понаслышке.
Ситуация такова, что объект не предоставляет методов копирования через оператор=, и вдобавок он является сложным (содержит внутри объекты и указатели). Однако вы позволяете наплевать на все правила и просто скопировать содержимое такого объекта - фактически через memcpy (суть та же самая) и работать с ним как с новым объектом. Я вам уже привёл пример в прошлом сообщении, какие возможны последствия от такой безконтрольной самодеятельности: динамические private объекты, созданные и используемые исключительно внутри класса, вдруг в одночасье оказываются удалёнными, либо вдруг начинают "чудить", самопроизвольно изменяться - а всё потому, что где-то кто-то скопировал содержимое нашего объекта через memcopy и теперь управляет нашими внутренними private-объектами. Это нонсенс.
И речь не обязательно о сторонних пользователях, не знакомых с реализацией класса. Ты сам можешь где-то в программе случайно сделать приравнивание объектов, и компилятор такое пропустит без ошибок.
До сих пор осталась старая проблема - удаляются некоторые не выделенные объекты при нажатии на del. При этом они не возвращаются обратно при попытке откатить действие. Обычно это происходит с объектами с которыми ты недавно работал. То ли терминал их не показывает выделенными, а на самом деле они такими остаются, то ли еще какая причина. Это очень не удобно, приходится постоянно жать на "сохранить шаблон".
Нет, в данном контексте не программист, а именно пользователь класса. Вы видимо рассуждаете с позиции структурно-процедурного программиста, самостоятельно контролирующего всё и вся, досконально знающего внутреннюю реализацию всех объектов, с которыми он работает.
Я веду речь об объектно-ориентированном подходе. Одним из основополагающих принципов тут является инкапсуляция, если вам знакомо это понятие. В рамках этой парадигмы конкретная реализация любого объекта скрыта от посторонних глаз и является исключительно внутренним делом этого объекта. А пользователь довольствуется тем функционалом, который предоставляет этот объект с помощью публичных методов. Внутренности нас вообще не касаются. Тем более что реализацию этих внутренностей возможно программировал другой человек. В общем странно, что я тут вынужден объяснять эти азы, хотя казалось бы, вы должны быть знакомы с ними не понаслышке.
Ситуация такова, что объект не предоставляет методов копирования через оператор=, и вдобавок он является сложным (содержит внутри объекты и указатели). Однако вы позволяете наплевать на все правила и просто скопировать содержимое такого объекта - фактически через memcpy (суть та же самая) и работать с ним как с новым объектом. Я вам уже привёл пример в прошлом сообщении, какие возможны последствия от такой безконтрольной самодеятельности: динамические private объекты, созданные и используемые исключительно внутри класса, вдруг в одночасье оказываются удалёнными, либо вдруг начинают "чудить", самопроизвольно изменяться - а всё потому, что где-то кто-то скопировал содержимое нашего объекта через memcopy и теперь управляет нашими внутренними private-объектами. Это нонсенс.
И речь не обязательно о сторонних пользователях, не знакомых с реализацией класса. Ты сам можешь где-то в программе случайно сделать приравнивание объектов, и компилятор такое пропустит без ошибок.
Если правильно понимаю, проблема возникнет с объектами, схожими с синглтоном. Лучший аргумент в данном случае - привести короткий код в качестве демонстрации сказанного
Программист, со всеми вытекающими обязательствами. Бездумно скопировали сложный объект, значит сами виноваты.
Неявный оператор копирования - это не memcpy, а реальное конструирование каждого сложного объекта внутри структуры или класса.