Ошибки, баги, вопросы - страница 313

[Владимир]

Почему-то не могу получить текущую прибыль по счёту в функции OnTester

 Вот так получаю 0

double OnTester()
{
   return(AccountInfoDouble(ACCOUNT_PROFIT));
} 

 

А вот так приходится получать прибыль: 

double OnTester()
{
   return(AccountInfoDouble(ACCOUNT_BALANCE)-100000);
} 

[Academic]

stringo:

Об чём спорим? w0 не ставить

PS Сообщение обязательно будет (возможно несколькими строчками ниже) 

Слава согласен - все эти споры отнимают столько времени, ну их ( споры ) нафиГ. :) 

Но так, что называется на ход ноги  - Вы же, я уверен сами все прекрасно знаете, но все же если эта функция внешняя и объявлена только через декларацию, то есть такие модификаторы как "const" и "in" и "out". И наверное тут с этой функции есть недочет. Дело в том - что если это возвращаемый параметр то в случае попытки его не возврата ( в случае если он возвращается через "return" ) выдается предупреждение а наличие второй формы функции, когда возвращаемое значение возвращается через параметр, также должно выдаваться предупреждение, так как это возвращаемое значение. Иначе если бы сделать так чтобы результат успех/не успех возвращался бы чрез параметр, а само значение через return то не вернуть было бы нельзя. А успех или не успех также ВСЕГДА возвращается. Иными словами - ( http://users.telenet.be/bart.demeyere/C++InOutParameters.html ) вот решение которое давно уже есть. 

Но разговор вообще как я заметил не о чем. ИМХО, вам надо отвечать на подобные вопросы, если вы ничего не планируете уже менять кардинальное в текущей реализации примерно так :) - "Да, есть такая проблема, она будет решена в следующих вересиях программы, сейчас мы зафиксировали код, и исправляем только ошибки." Никто ( я думаю даже из самых не адекватных ) не обидятся, но просто сама фиксация проблемы важна и нужна.

Так будет или нет в этой версии такие очень ( НУ ОЧЕНЬ ) полезные модификаторы in out  и прочие, они существенно позволяют минимизировать ошибки.

***

Пол дня уйдет на все эти переписку. Я завязываю. :)

[Rashid Umarov]

Erm955:

Почему-то не могу получить текущую прибыль по счёту в функции OnTester

 Вот так получаю 0

double OnTester()
{
   return(AccountInfoDouble(ACCOUNT_PROFIT));
} 

 

А вот так приходится получать прибыль: 

double OnTester()
{
   return(AccountInfoDouble(ACCOUNT_BALANCE)-100000);
} 

Объявляем глобальную переменную и в OnInit() присваиваем ей текущее значение баланса.

В OnTester() вычисляем итоговую прибыль по результатам всех проведенных сделок:

Профит=ТекущийБбаланс - Начальный баланс

и выдаем в OnTester().

А то что Вы пытаетесь получить сейчас - это текущая незафиксированная прибыль, которая равна нулю, если все позиции закрыты.

[Slava]

Academic:

Слава согласен - все эти споры отнимают столько времени, ну их ( споры ) нафиГ. :) 

Так будет или нет в этой версии такие очень ( НУ ОЧЕНЬ ) полезные модификаторы in out  и прочие, они существенно позволяют минимизировать ошибки.

"Об чём спорим?" - фраза из моего детства, которая означает "на что спорим?"

Передача параметра по ссылке как раз и означает inout. Просто бывают реализации неподвластные компилятору.

На самом деле, совершенно несложно анализировать поток выполнения, заходя в функции (пример, который представил Рашид). Мы сознательно отказались от этого подхода. По той самой причине, что время компиляции из-за этого может существенно увеличиться. Поэтому мы пошли на самый простой вариант - выдачу предупреждения. А что, лучше не выдавать такого предупреждения? Нет, надо. Сделаете явную инициализацию - предупреждения не будет.

Также повторяю, что у нас предусмотрена укороченная оценка логических выражений. Это означает в Вашем случае, что если первый ObjectGetDouble вернёт false (например потому, что объекта, заметьте внешнего по отношению к программе, вдруг не существует), то второй ObjectGetDouble не вызовется

[Academic]

stringo:

"Об чём спорим?" - фраза из моего детства, которая означает "на что спорим?"

Передача параметра по ссылке как раз и означает inout. Просто бывают реализации неподвластные компилятору.

На самом деле, совершенно несложно анализировать поток выполнения, заходя в функции (пример, который представил Рашид). Мы сознательно отказались от этого подхода. По той самой причине, что время компиляции из-за этого может существенно увеличиться. Поэтому мы пошли на самый простой вариант - выдачу предупреждения. А что, лучше не выдавать такого предупреждения? Нет, надо. Сделаете явную инициализацию - предупреждения не будет.

Также повторяю, что у нас предусмотрена укороченная оценка логических выражений. Это означает в Вашем случае, что если первый ObjectGetDouble вернёт false (например потому, что объекта, заметьте внешнего по отношению к программе, вдруг не существует), то второй ObjectGetDouble не вызовется

Верно, не вызовется - это стандартное поведение Сишных кодов.

Модификаторы in и out можут быть по мимо ссылок. И по умолчанию для ссылок они именно in и out всегда. Но я могу передать ссылку с модификатором in это значит что этот параметер функции всегда вводится и запись в него не возможна, хоть и передан он по ссылке. Вы читали ? http://users.telenet.be/bart.demeyere/C++InOutParameters.html

in: parameter will be read (warning when not read in every branch*)
(in): parameter can be read (warning when nowhere read)
out: parameter will be written to (warning when not written to in every branch*)
(out): parameter can be written to (warning when nowhere written to)
in without out: parameter cannot be written to
out without in: parameter cannot be read before it is written to.
*in every branch: in all possible normal flows through the function (both branches in an if statement, all branches in a case statement,... ), but not when an exception is thrown. This is the same constraint as for a return statement, to have no undefined behavior.

And above all, introducing the keywords in and out, can help us find some problems already at compile time. And don't we all want to find errors as soon as possible

[Slava]

Есть модификатор const. Передача константной ссылки однозначно предполагает параметр in безо всякого out. Мы точно не будем вводить дополнительные сущности in, out, inout

[Academic]

stringo:

Есть модификатор const. Передача константной ссылки однозначно предполагает параметр in безо всякого out. Мы точно не будем вводить дополнительные сущности in, out, inout

Не будите значит не будите. Но Вы должны понимать что приличной оптимизации тогда не получить. И если бы в том примере стояло бы OUT то предупреждения выдавать не надо было. Но вообще напрасно - ИМХО, делов на три минуты но зато насколько ошибок меньше. А не хочешь не используй. Тогда все как всегда. Ну как сейчас. :)

Как сделать у вас только OUT без IN?  Чистый OUT? Что означает что всегда что-то возвращается, ну как возврат функции?

[[Удален]]

Разработчикам.

1. Я так понял, что спред по основным парам забит с мая  1993 года, примерно 930 недельных баров на текущий момент?

Причем на глубокой истории бары строились на основе дневок.

Следовательно, советники можно тестировать начиная именно с мая 1993 (если использовать ТФ не меньше D1)?

2. А можно по GBPUSD историю посмотреть глубже 09.05.1993 (как к примеру это реализовано по EURUSD)?

[MathX]

Здравствуйте.

Поясните пож-та, кто знает, почему при "ручном"  создании объекта "Графическая метка" ему не выставляется указанный bmp файл для состояний вкл/выкл?

Вот код: 

ObjectCreate(....);    

....... 

ObjectSetString(0, "ColorLabel", OBJPROP_BMPFILE, 0, "Images\on.bmp");
ObjectSetString(0, "ColorLabel", OBJPROP_BMPFILE, 1, "Images\off.bmp"); 

Метка создается полностью корректно, в указанной позиции, с заданными цветами и тд, но не указываются  "Images\on.bmp" и "Images\off.bmp". Если в гуи МТ5
щелкнуть на списке объектов и руками выставить эти файлы для метки - они выставятся. Но почему  ObjectSetString этого не делает?

Что скажите? 

[Ilyas]

MathX:

Что скажите? 

Попробуйте

ObjectSetString(0, "ColorLabel", OBJPROP_BMPFILE, 0, "\\Images\\on.bmp");
ObjectSetString(0, "ColorLabel", OBJPROP_BMPFILE, 1, "\\Images\\off.bmp");

Изменения в справке будут в ближайшее время.