Пока что не могу придумать пользы от этой библиотеки.
На форексе она точно не нужна, а на бирже нет необходимости.
Если Вы про частичное исполнение, то оно вовсю работает на форексе. В частности, поэтому на форексе очень даже востребована асинхронность, а значит и данная библиотека может быть полезной.
Тестировали данную библиотеку на бирже?
На бирже не тестировал, но биржа и форекс для библиотеки - технически одно и то же. Вы просто получаете данные о всех транзакциях в любом месте, когда захотите. Только и всего. Поэтому от типа рынка здесь ничего не зависит.
В каком случае по вашему она может пригодиться?
Библиотека пригодится тогда же, когда пригодится асинхронность. А этом любая массовая (больше одного) отправка торговых приказов. Сценариев может быть много:
Нужно экспериментировать. Думаю, что одновременная запись/чтение ресурса действует также, как и с глобальными переменными, т.к. запись в обоих случаях - это создание: ResourceCreate и GlobalVariableSet. Единственное отличие ресурса от глобальной - невозможно даже теоретически что-либо писать в ресурс одновременно. С глобальными - возможно.
Фактически, чтение ресурса - это получение куска данных из памяти. И если чтение началось, то запись ресурса не должна повлиять, т.к. запись - это выделение другого куска памяти. Пересекаться они вряд ли могут, т.к. это, скорее всего, не даст сделать сама ОС. Поэтому, с моей точки зрения, конфликтов load/save с ресурсами быть не должно. Но лучше, конечно, задать этот вопрос разработчикам.
А разве ресурс с одним именем — это не тот же ресурс (и кусок памяти, соответственно)?
Проверить легко — нужно записывать что-то длинное, со специальной меткой в конце, и параллельно читать. Если будет прочитано не целое сообщение, значит, конфликт может быть.
А разве ресурс с одним именем — это не тот же ресурс (и кусок памяти, соответственно)?
Запись - это создание другого ресурса.
Проверить легко — нужно записывать что-то длинное, со специальной меткой в конце, и параллельно читать. Если будет прочитано не целое сообщение, значит, конфликт может быть.
#property script_show_inputsinputbool Save = true; // Save/Load#include <fxsaber\TradeTransactions\ResourceData.mqh> // https://www.mql5.com/ru/code/22166#define MINLENGTH 100000#define _CS(A) ((!::IsStopped()) && (A))
voidOnStart()
{
const RESOURCEDATA<int> Resource("::Test");
int Array[];
while (_CS(true))
if (Save)
for (int i = 0; _CS(i < MINLENGTH); i++)
{
constint Size = ArrayResize(Array, i + MINLENGTH);
Array[Size - 1] = Size;
Resource = Array;
}
else
{
ArrayResize(Array, 0);
constint Size = Resource.Get(Array);
if (!Size || (Array[Size - 1] != Size))
{
Print(Size);
break;
}
}
}
Этот проверочный скрипт показывает, что конфликтов не возникает.
Вы когда-нибудь думали о том, чтобы использовать стандартные соглашения о стиле/именовании C++? Лично я считаю ваш код великолепным, но причина, по которой я не использую ваши библиотеки (или вынужден их рефакторить), заключается в используемом стиле. Очень трудно мысленно разобрать некоторые части вашего кода просто потому, что вы не следуете никаким стандартным соглашениям. Это особенно расстраивает тех, кто пришел из других языков. Например, в этой библиотеке все названо в CamelCase, кроме объявления класса (ALLCAPS), что идет вразрез с любыми соглашениями об именовании почти во всех языках программирования. Взгляд на код расстраивает, потому что во многих других языках
CamelCase.thing
обращается к атрибуту класса, а не к атрибуту экземпляра.
То же самое относится и к объявлениям классов, а вы так любите использовать макросы, что я никогда не знаю, являются ли ваши объявления классов макросами или перечислениями. Обычно, согласно стандартным соглашениям MQL, вы должны использовать ALLCAPS только для перечислений, макросов и констант - а CamelCase используется для объявлений классов. Кроме того, в соответствии с конвенцией MQL переменные определяются с использованием snake_case.
Я не хотел обидеть вас своей конструктивной критикой, и я знаю, что вы очень много работаете, чтобы сделать эти библиотеки бесплатными для всех, и это здорово, и нам нужно больше таких разработчиков, как вы. Я знаю, что говорю не только за себя, и если бы вы просто внесли небольшие изменения в применяемый стиль, то больше разработчиков использовали бы ваши библиотеки. Вы ведь этого хотите, не так ли?
Пока что не могу придумать пользы от этой библиотеки.
На форексе она точно не нужна, а на бирже нет необходимости.
Если Вы про частичное исполнение, то оно вовсю работает на форексе. В частности, поэтому на форексе очень даже востребована асинхронность, а значит и данная библиотека может быть полезной.
Тестировали данную библиотеку на бирже?
На бирже не тестировал, но биржа и форекс для библиотеки - технически одно и то же. Вы просто получаете данные о всех транзакциях в любом месте, когда захотите. Только и всего. Поэтому от типа рынка здесь ничего не зависит.
В каком случае по вашему она может пригодиться?
Библиотека пригодится тогда же, когда пригодится асинхронность. А этом любая массовая (больше одного) отправка торговых приказов. Сценариев может быть много:
Нужно экспериментировать. Думаю, что одновременная запись/чтение ресурса действует также, как и с глобальными переменными, т.к. запись в обоих случаях - это создание: ResourceCreate и GlobalVariableSet. Единственное отличие ресурса от глобальной - невозможно даже теоретически что-либо писать в ресурс одновременно. С глобальными - возможно.
Фактически, чтение ресурса - это получение куска данных из памяти. И если чтение началось, то запись ресурса не должна повлиять, т.к. запись - это выделение другого куска памяти. Пересекаться они вряд ли могут, т.к. это, скорее всего, не даст сделать сама ОС. Поэтому, с моей точки зрения, конфликтов load/save с ресурсами быть не должно. Но лучше, конечно, задать этот вопрос разработчикам.
А разве ресурс с одним именем — это не тот же ресурс (и кусок памяти, соответственно)?
Проверить легко — нужно записывать что-то длинное, со специальной меткой в конце, и параллельно читать. Если будет прочитано не целое сообщение, значит, конфликт может быть.
А разве ресурс с одним именем — это не тот же ресурс (и кусок памяти, соответственно)?
Запись - это создание другого ресурса.
Проверить легко — нужно записывать что-то длинное, со специальной меткой в конце, и параллельно читать. Если будет прочитано не целое сообщение, значит, конфликт может быть.
Этот проверочный скрипт показывает, что конфликтов не возникает.
Запись - это создание другого ресурса.
Этот проверочный скрипт показывает, что конфликтов не возникает.
Я имел в виду что-то такое:
Похоже, действительно не теряется.
Я имел в виду что-то такое:
Похоже, действительно не теряется.
Такой вариант проверки не учитывает изменение размера ресурса и данных на его конце.
Такой вариант проверки не учитывает изменение размера ресурса и данных на его конце.
В памяти могут оставаться записанные ранее данные? Как очистить?
В памяти могут оставаться записанные ранее данные?
Теоретически это можно допустить. Поэтому нужно и это проверять.
Как очистить?
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Библиотеки: TradeTransactions
fxsaber, 2018.09.20 16:23
ResourceINT.Free(); // Удалили данные из ресурсаОчистка ресурса - удаление.
Теоретически это можно допустить. Поэтому нужно и это проверять.
С двумя строками разной длины ошибок тоже нет:
С двумя строками разной длины ошибок тоже нет:
Все так. К тому высказался, что изначальный код это проверял.
обращается к атрибуту класса, а не к атрибуту экземпляра.
То же самое относится и к объявлениям классов, а вы так любите использовать макросы, что я никогда не знаю, являются ли ваши объявления классов макросами или перечислениями. Обычно, согласно стандартным соглашениям MQL, вы должны использовать ALLCAPS только для перечислений, макросов и констант - а CamelCase используется для объявлений классов. Кроме того, в соответствии с конвенцией MQL переменные определяются с использованием snake_case.
Я не хотел обидеть вас своей конструктивной критикой, и я знаю, что вы очень много работаете, чтобы сделать эти библиотеки бесплатными для всех, и это здорово, и нам нужно больше таких разработчиков, как вы. Я знаю, что говорю не только за себя, и если бы вы просто внесли небольшие изменения в применяемый стиль, то больше разработчиков использовали бы ваши библиотеки. Вы ведь этого хотите, не так ли?