Разработчики, с какой целью в таймсериях Стандартной Библиотеки стоит ограничение на годовой размер таймсерии ? - страница 2

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

Я просто закомментарил этот свитч в коде Стандартной Библиотеки - и все стало работать очень даже нормально, советник можно запускать на все 15 лет торговли (дневки евродоллара). Ошибок нет.

По идее, я сперва просто собирался перегрузить функцию BufferResize().

Проблема в том, что этот свич стоит очень "глубоко", в классе CSeries, а функция  BufferResize() определена в каждом классе иерархии, добавляя что-то свое.

То есть, для работы с Таймсериями я  использую классы-наследники, получается иерархия:

CMyOpen:

CiOpen

CPriceSeries

CSeries

То есть, при перегрузке функции в наследнике, в нем придется "собрать" весь код предков вплоть до CSeries.

Плюс к этому - класс CPriceSeries является базовым для всех классов ценовых таймсерий OHLC.  Соответственно, данный код придется без изменения копировать во все четыре наследника высокого уровня (CMyOpen, CMyHigh, CMyLow,CMyClose).

Получается весьма некрасиво.

Ну а главное - мне все-таки непонятна причина, по которой в код включено это ограничение.

Возможно, есть какие-то "подводные камни"...

TheXpert: А от некоторых решений в стандартной  библиотеке MQL иногда волосы дыбом.

И не говори, дружище.

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

Ну что же... Обращусь в Сервисдеск.

 

Можете не обращаться в сервисдеск.

Мы не можем ответить на вопрос "почему так сделано".  Так было сделано с самого начала и никаких изменений после не было.

Мы уберём эти ограничения. Ждите следующего билда.

Спасибо.

 
stringo:

Можете не обращаться в сервисдеск.

Мы не можем ответить на вопрос "почему так сделано".  Так было сделано с самого начала и никаких изменений после не было.

Мы уберём эти ограничения. Ждите следующего билда.

Спасибо.

О ! Премного благодарен.

Просто я опасался, что там есть какие-то моменты, про которые я не знаю, и это ограничение на размер таймсерии важно.

Спасибо.

Заявку в Сервисдеске убираю.

 
TheXpert:

А от некоторых решений в стандартной  библиотеке MQL иногда волосы дыбом.

Это от каких например?
 
stringo:

Можете не обращаться в сервисдеск.

Мы не можем ответить на вопрос "почему так сделано".  Так было сделано с самого начала и никаких изменений после не было.

Мы уберём эти ограничения. Ждите следующего билда.

Спасибо.

Исправьте заодно ошибку и в CArrayObj::SearchLessOrEqual(). У меня уже больше недели в сервисдеске висит соответствующий тикет #1182907 и ответа до сих пор нет. Если вкратце, данный код не находит нужный элемент:

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
//---
   CArrayObj object;
   object.Sort(0);
   for(int i = 0; i < 10; i++)
      object.InsertSort(new IntObject(i));
   
   int index = object.SearchLessOrEqual(object.At(0));
   if(index == -1)
      printf("ERROR! Search function not find element 0");
   else
      printf("Searching work well.");
  }
//+------------------------------------------------------------------+

Вывод:

2015.03.21 21:51:25.184 TestSearchLess (USDCAD,M1)      ERROR! Search function not find element 0
 

И раз уж мы начали говорить о стандартной библиотеке, еще одна просьба: пожалуйста, оптимизируйте метод CArrayObj::InsertSort:

 

Идея в том, что бы избежать лишний раз ресурсоемкой переразметки CArrayObj::MemMove. У меня в проекте этот метод занимает 34% времени выполнения, хотя в 99,9 случаев элемент добавляется именно в конец массива.  

 
Mikalas:

P/S komposter, оказывается не я один такой непонятливый. 

Голова готова к посыпанию пеплом? ;)
 
stringo:

Можете не обращаться в сервисдеск.

Мы не можем ответить на вопрос "почему так сделано".  Так было сделано с самого начала и никаких изменений после не было.

Мы уберём эти ограничения. Ждите следующего билда.

Спасибо.

это наверное когда компы еще были калькуляторами с внешним дисплеем, вах наверное сколько народу об эти грабли разочаровалось в мт
 
C-4: Идея в том, что бы избежать лишний раз ресурсоемкой переразметки CArrayObj::MemMove. У меня в проекте этот метод занимает 34% времени выполнения, хотя в 99,9 случаев элемент добавляется именно в конец массива.  

Что-то я не вполне пойму... Там нет вызова MemMove для вставки в конец массива.

Вот код (по-моему, вполне неплохой):

bool CArrayObj::Insert(CObject *element,const int pos)
  {
//--- check
   if(pos<0 || !CheckPointer(element))
      return(false);
//--- check/reserve elements of array
   if(!Reserve(1))
      return(false);
//--- insert
   m_data_total++;
   if(pos<m_data_total-1)
     {
      MemMove(pos+1,pos,m_data_total-pos-1);   // ВОТ ПЕРЕРАЗМЕТКА - ОНА ДЕЙСТВУЕТ ВЕЗДЕ, КРОМЕ ПОСЛЕДНЕГО ЭЛЕМЕНТА
      m_data[pos]=element;
     }
   else
      m_data[m_data_total-1]=element; // ДЛЯ ПОСЛЕДНЕГО ЭЛЕМЕНТА ПЕРЕРАЗМЕТКИ НЕТ
   m_sort_mode=-1;
//--- successful
   return(true);
  }

Где тут переразметка ?

Я бы поглядел в сторону вызова Reserve() - похоже, у вас каждый раз выделяется память под один элемент, это нерационально, и допустимо только если вы заранее не знаете, сколько у вас элементов будет добавлено. (А даже если и не знаете, стоит резервировать не по одной, а сразу по блоку записей)

12
Новый комментарий
Причина обращения: