Сделайте сервис аттестации программистов ... - страница 6

 

Дааа ребяты....

уже можно оценки выставлять :)))) 

 
VOLDEMAR:
Ну так не можете ничего путевого сказать , так молчите или по делу говорите ....  Если б знали хоть что то то показали ...  Или жалко ??? Или не знаете ничего ....

тут спор ни о чем.

Реально лучше бы перечесали свои функции отправки ордеров на корректность отправляемого на сервер ордера.

Что бы сообщение об ошибке было не после получения с сервера ошибки, а до неё )
Документация по MQL5: Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений / Ошибки компиляции
Документация по MQL5: Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений / Ошибки компиляции
  • www.mql5.com
Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений / Ошибки компиляции - Документация по MQL5
 
MrGold166:
В этом и смысл перебора с конца, ничего военного в том что мы обработали один ордер дважды нет. в худшем случае это нам помешает только если мы считаем ордера, например среднюю цену, один ордер будет посчитан 2 раза. даже если это сильно вмешается в расчеты, на следующем тике все вернется на свои места и мы поставим тейк профит там где он должен быть. На моей памяти при количеств ордеров более 50 и самом худшем  так называемом "брокере" Азии (да да вы поняли о ком я, на I называется) же после того как счет был взят в оборот (сами знаете зачем) такого не происходило не разу. Но и этого можно избежать:

int i,last_ticket;
for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {
   if(OrderTicket()==last_ticket) continue;
   last_ticket=OrderTicket();
   }

А чем вы можете гарантировать, что при следующем тике вы не получите такую же ситуацию, да ничем.

И может наступить худший случай, вы посчитаете неправильно среднюю и откроете неправильно ордер и следующий тик не будет иметь значение.

Важно не количество ордеров, а торговое окружение, наличие реальных стопов, наличие других советников на счете.

 
MrGold166:
Но и этого можно избежать:

int i,last_ticket;
for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {
   if(OrderTicket()==last_ticket) continue;
   last_ticket=OrderTicket();
   }
Теоретически может измениться состояние более чем одного ордера
 
A100:
Теоретически может изменится состояние более чем одного ордера

Здравая идея, я не подумал о двух, зациклился на одном.

Вот и вернулись к исходной, так как же решить коллизии с этой функцией.

 
sandex:

Здравая идея, я не подумал о двух, зациклился на одном.

Вот и вернулись к исходной, так как же решить коллизии с этой функцией.

   int j=OrdersTotal();
   for(int i=j-1;i>=0;i--)
   {
      if(OrderSelect(i,SELECT_BY_POS))
      {
      }
   }
   if(j!=OrdersTotal())return(0);

если уж на то пошло то пересчитывать по новой. если на входе и на выходе количество ордеров не равно.

 
A100:
Теоретически может измениться состояние более чем одного ордера

и че? да хоть все изменятся мы все равно не будем анализировать одни и те же сделки.

Если же мы говорим о том что сделка выше по списку изменилась то она может изменится и после перебора - до того как мы будем выставлять общий профит.  

 
snowman:

если уж на то пошло то пересчитывать по новой если на входе и на выходе количество ордеров не равно.

В общем случае даже количество ордеров может быть равно, только это могут быть разные ордера
 
snowman:

если уж на то пошло то пересчитывать по новой. если на входе и на выходе количество ордеров не равно.

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

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

 
MrGold166:

и че? да хоть все изменятся мы все равно не будем анализировать одни и те же сделки.

Если же мы говорим о том что сделка выше по списку изменилась то она может изменится и после перебора - до того как мы будем выставлять общий профит.  

Я имел ввиду расчет не применительно к конкретной ситуации, а общий случай. Думаю повторный учет и/или недоучет чего либо всё же имеет значение, иногда - критическое
Причина обращения: