Странный баг - страница 2

Новый комментарий
 
Комбинатор:
Серьезно что ли? Мне до зубовного скрежета достало в свое время выкорчевывать баги из его кода, тем более что пользовалось народу этим кодом довольно много

Если не секрет, что там не так? Какие именно баги были?

 
Dmitiry Ananiev:

много лет пользовался функцией закрытия ордеров вот такой: 

if(OrderSelect(cnt,SELECT_BY_POS,MODE_TRADES) && OrderSymbol()==_Symbol && OrderMagicNumber()==mag)

Вроде правильно отрабатывает:

#property strict
//+------------------------------------------------------------------+
void OnStart()
  {
   if(f1() && f2() && f3())
   Print("=Yes=");
   else Print("=No=");
  }
//+------------------------------------------------------------------+
bool f1() { Print("f1"); return(true); }
bool f2() { Print("f2"); return(true); }
bool f3() { Print("f3"); return(true); }

результат:

2017.11.10 12:57:12.725 Test-if USDCHF,M15: =Yes=

2017.11.10 12:57:12.725 Test-if USDCHF,M15: f3

2017.11.10 12:57:12.725 Test-if USDCHF,M15: f2

2017.11.10 12:57:12.725 Test-if USDCHF,M15: f1

Всё равно, условия с функциями лучше не использовать в одном if.
 
Artyom Trishkin:

Если не секрет, что там не так? Какие именно баги были?

Вы хотите чтобы я вспомнил баги которые чинил лет 5 назад? Помню что были, помню что продираться через код с его стилем довольно неприятно.

Он несомненно заслуживает уважения за проделанную работу и наработанную базу кода, но нимб на ним рисовать не стоит.

 
Комбинатор:

Возможно бага. Есть подозрение что OrderSymbol или OrderMagicNumber вызывается раньше OrderSelect из-за UB вычисления аргументов.

А бага в том, что для операторов && и || аргументы должны вычисляться по порядку, без UB. Если я опять же ничего не путаю.


Я тоже пришел к похожему выводу. Выделил OrderSlect в отдельный if и в скобочки и все стало нормально. И когда то раньше так всегда и писал, но зрительно не нравилась конструкция с кучей фигурных скобок. Потом у кого то увидел такое объединение и стал так писать. 

Вывод писать код нужно так, чтоб исключить различные двоечтения.

 
Dmitiry Ananiev:

Я тоже пришел к похожему выводу. 


Чтобы прийти здесь хоть к какому-то выводу -- надо сделать отладку в логах -- тогда будет точно понятно что и почему.

Вероятность смены приоритета и порядка операций -- равна нулю.

Вероятность, что причина именно в вашем коде -- 100%.

 
Комбинатор:
Вы хотите чтобы я вспомнил баги которые чинил лет 5 назад? Помню что были, помню что продираться через код с его стилем довольно неприятно.

Он несомненно заслуживает уважения за проделанную работу и наработанную базу кода, но нимб на ним рисовать не стоит.

Стиль написания - не баг.

Впрочем, кому как. Мне его логика с ходу понятна. Но не пользовался его функциями - много лишнего из-за универсальности. Да и цикл при каждом вызове функции - тормоза.

Но так, чтобы что-то не отрабатывало, такого не было ни у кого - не было вопросов на форуме по неработоспособности его функций.

 

Использовать обязательно

#property strict

для правильной отработки логических конструкций.

 
Artyom Trishkin:

Стиль написания - не баг.

Впрочем, кому как. Мне его логика с ходу понятна. Но не пользовался его функциями - много лишнего из-за универсальности. Да и цикл при каждом вызове функции - тормоза.

Но так, чтобы что-то не отрабатывало, такого не было ни у кого - не было вопросов на форуме по неработоспособности его функций.


Да это the-эксперт сделал вброс. "Нимб", "стиль" -- типичный the-вброс.

 
fxsaber:

Использовать обязательно

для правильной отработки логических конструкций.


Кстати да, Второй советник писался наспех и не было этого вставлено, Возможно еще и поэтому баг проявился, но теперь и вставил этот оператор и исправил саму функцию.

 
Dmitiry Ananiev:

Кстати да, Второй советник писался наспех и не было этого вставлено, Возможно еще и поэтому баг проявился, но теперь и вставил этот оператор и исправил саму функцию.


Попробуйте сделать отладку в логах работы старого варианта и нового. Думаю, в чём причина -- было бы интересно узнать.

123
Новый комментарий