Разработчики, с какой целью в таймсериях Стандартной Библиотеки стоит ограничение на годовой размер таймсерии ? - страница 2
![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я просто закомментарил этот свитч в коде Стандартной Библиотеки - и все стало работать очень даже нормально, советник можно запускать на все 15 лет торговли (дневки евродоллара). Ошибок нет.
По идее, я сперва просто собирался перегрузить функцию BufferResize().
Проблема в том, что этот свич стоит очень "глубоко", в классе CSeries, а функция BufferResize() определена в каждом классе иерархии, добавляя что-то свое.
То есть, для работы с Таймсериями я использую классы-наследники, получается иерархия:
CMyOpen:
CiOpen
CPriceSeries
CSeries
То есть, при перегрузке функции в наследнике, в нем придется "собрать" весь код предков вплоть до CSeries.
Плюс к этому - класс CPriceSeries является базовым для всех классов ценовых таймсерий OHLC. Соответственно, данный код придется без изменения копировать во все четыре наследника высокого уровня (CMyOpen, CMyHigh, CMyLow,CMyClose).
Получается весьма некрасиво.
Ну а главное - мне все-таки непонятна причина, по которой в код включено это ограничение.
Возможно, есть какие-то "подводные камни"...
TheXpert: А от некоторых решений в стандартной библиотеке MQL иногда волосы дыбом.
И не говори, дружище.
Но, все же, большинство идей, лежащих в основе Стандартной Библиотеки - очень даже здравые, и я в своем коде очень широко использую ее классы.
Ну что же... Обращусь в Сервисдеск.
Можете не обращаться в сервисдеск.
Мы не можем ответить на вопрос "почему так сделано". Так было сделано с самого начала и никаких изменений после не было.
Мы уберём эти ограничения. Ждите следующего билда.
Спасибо.
Можете не обращаться в сервисдеск.
Мы не можем ответить на вопрос "почему так сделано". Так было сделано с самого начала и никаких изменений после не было.
Мы уберём эти ограничения. Ждите следующего билда.
Спасибо.
О ! Премного благодарен.
Просто я опасался, что там есть какие-то моменты, про которые я не знаю, и это ограничение на размер таймсерии важно.
Спасибо.
Заявку в Сервисдеске убираю.
А от некоторых решений в стандартной библиотеке MQL иногда волосы дыбом.
Можете не обращаться в сервисдеск.
Мы не можем ответить на вопрос "почему так сделано". Так было сделано с самого начала и никаких изменений после не было.
Мы уберём эти ограничения. Ждите следующего билда.
Спасибо.
Исправьте заодно ошибку и в CArrayObj::SearchLessOrEqual(). У меня уже больше недели в сервисдеске висит соответствующий тикет #1182907 и ответа до сих пор нет. Если вкратце, данный код не находит нужный элемент:
Вывод:
И раз уж мы начали говорить о стандартной библиотеке, еще одна просьба: пожалуйста, оптимизируйте метод CArrayObj::InsertSort:
Идея в том, что бы избежать лишний раз ресурсоемкой переразметки CArrayObj::MemMove. У меня в проекте этот метод занимает 34% времени выполнения, хотя в 99,9 случаев элемент добавляется именно в конец массива.
P/S komposter, оказывается не я один такой непонятливый.
Можете не обращаться в сервисдеск.
Мы не можем ответить на вопрос "почему так сделано". Так было сделано с самого начала и никаких изменений после не было.
Мы уберём эти ограничения. Ждите следующего билда.
Спасибо.
Что-то я не вполне пойму... Там нет вызова 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() - похоже, у вас каждый раз выделяется память под один элемент, это нерационально, и допустимо только если вы заранее не знаете, сколько у вас элементов будет добавлено. (А даже если и не знаете, стоит резервировать не по одной, а сразу по блоку записей)