Когда изучаешь код (особенно чужой), то часто используется в редакторе ALT+G для соответствующего перехода. Нажимая так несколько раз ALT+G углубляешься в вложенности функций/методов. И когда понимаешь смысл, хочется на один шаг вернуться обратно (туда, где нажал ALT+G). Когда там понял - еще раз на один шаг назад. Как это сделать?
Если у Buy-позиции ценовой уровень TP совпадает с ценой выставленного SellLimit, то в бэктесте (не hedge-режим) SellLimit очень часто срабатывает раньше TP. Правильно ли в такой ситуации совпадения цен, чтобы тестер всегда сначала исполнял TP, а только потом лимитный ордер?
Поскольку сейчас такого приоритета нет, то описанная ситуация разруливается в тестере случайно.
Например, когда SellLimit_Price == BuyTP_Price, SellLimit_Lots = Buy_Lots, в тестере возникает неоднозначность:
сначала срабатывает SellLimit - закрывается позиция. TP теряет смысл и в итоге нет открытых позиций.
Добрый вечер. кто сможет выручить с MQL 5. Я новичок совсем . А на сколько я могу понимать суть проблемы в мелочевке . Настраиваю параболика делаю кампеляцию , а он после не хочет тестировать в МТ 5
Первоначально не придал этому значения, но столкнувшись с этим повторно - появились аргументы, что оно не правильное. И вот почему: далее условный код
int f()
{
while ( true )
{
//много строк c return, continue, без breakreturn0;
//много строк c return, continue, без breakreturn1;
//много строк c return, continue, без break
}
return Random(); //(*)написано по требованию MQL компилятора //строка 61
}
Рассуждения что ставить после while(true) {} сводятся к следующему: "Мы же там все-равно никогда не будем... return нужен только формально - чтобы компилятор сказал OK... значит - поставим там случайное значение - return Random();"
Спустя время вносим в код изменения и появляется необходимость поставить break внутри while В этом случае компилятор скажет: "OK: Да все нормально. Там же после while(true) {} есть код - значит случай break был предусмотрен ранее и наверняка среди этого множества строк уже есть такой же break. Все значения возврата уже были продуманы еще тогда - не парься!" И в итоге получим случайное значение.
А если бы первоначально не было строки (*), то компилятор скажет: "Error: Нее... так не пойдет... раньше break не было и нужно вернуть что-то осознанное"
Получается, что строка (*) не просто избыточна, а еще и увеличивает вероятность появления трудноуловимых ошибок
Первоначально не придал этому значения, но столкнувшись с этим повторно - появились аргументы, что оно не правильное...
Более того, в этом вашем примере по-хорошему нужно выдавать предупреждение "unreachable code". Студия такого предупреждения тоже не выдаёт, а вот борландовский компилятор, помнится, выдавал.
Например, когда SellLimit_Price == BuyTP_Price, SellLimit_Lots = Buy_Lots, в тестере возникает неоднозначность:
Если график инструмента открыт, то его (символ) скрыть невозможно...
Закройте график и тогда будет счастье...
Интересует вариант без "если" (см.текст полностью, а не только картинку)
Вариант без "если" - закрой график символа который хочешь скрыть и будет тебе счастье...
Выбирай на вкус...
Если график инструмента открыт, то его (символ) скрыть невозможно...
Закройте график и тогда будет счастье...
А то не знаем...
Хочешь сказать при закрытых графиках не скрывается символ?
Хочешь сказать при закрытых графиках не скрывается символ?
Да. Несколько раз уже сталкивался с такой бякой.
Все равно сообщение об ошибке правильное.
Первоначально не придал этому значения, но столкнувшись с этим повторно - появились аргументы, что оно не правильное. И вот почему: далее условный код
Рассуждения что ставить после while(true) {} сводятся к следующему: "Мы же там все-равно никогда не будем... return нужен только формально - чтобы компилятор сказал OK... значит - поставим там случайное значение - return Random();"
Спустя время вносим в код изменения и появляется необходимость поставить break внутри while
В этом случае компилятор скажет: "OK: Да все нормально. Там же после while(true) {} есть код - значит случай break был предусмотрен ранее и наверняка среди этого множества строк уже есть такой же break. Все значения возврата уже были продуманы еще тогда - не парься!"
И в итоге получим случайное значение.
А если бы первоначально не было строки (*), то компилятор скажет: "Error: Нее... так не пойдет... раньше break не было и нужно вернуть что-то осознанное"
Получается, что строка (*) не просто избыточна, а еще и увеличивает вероятность появления трудноуловимых ошибок
Первоначально не придал этому значения, но столкнувшись с этим повторно - появились аргументы, что оно не правильное...