Отправлено: 13.09.14 21:28. Заголовок: Реализация структуры данных для мультивалютника

Когда я писал свои коды, я предвидел, что придётся когда-нить переписывать их с уклоном на мультивалютник.
На данный момент меня интересуют некоторые моменты. Начну с структуры:

struct Position_Properties
{
datetime gdt_Expiration; // Срок истечения отложенного ордера
datetime gdt_OpenTime; // Время открытия выбранной позиции
double gd_OpenPrice; // Цена открытия
double gd_Lots; // Объём позиции на открытие
double gd_CurSL; // Текущий Stop Loss выбранной позиции
double gd_NewSL; // Новый Stop Loss выбранной позиции
double gd_CurTP; // Текущий Take Profit выбранной позиции
double gd_NewTP; // Новый Take Profit выбранной позиции
int gi_CurTicket; // Тикет выбранного ордера
int gi_Type; // Тип торговой операции
int gi_Slippage; // Максимально допустимое отклонение цены для рыночных ордеров
int gi_Magic; // Магический номер
string gs_Comment; // Комментарий
string gs_Symbol; // Наименование фин. инструмента, с которым производится операция
ulong gu_Duration; // Длительность позиции в секундах
};

На данный момент, если пользоваться только параметрами, которые можно получить из параметров OrderSend() когда ордер выбран, данные параметры я записываю в структуру, и пользуюсь. Но это не есть универсальная структура. И, если торговать на разных инструментах и пользоваться всеми имеющимися здесь элементами-данными нужно как-то иначе реализовать задачу.
Я так думаю, что нужно каждый элемент чтоб был в виде 2-мерного массива наверное. Первое измерения массива будет - индекс торгуемого инструмента, а второе его характеристика.
Возможно ещё какие-то варианты есть, но я пока что не придумал.
Как это лучше реализовать? Я не совсем представляю.

 Отправлено: 15.09.14 08:56. Заголовок: hoz пишет: Но это н..

hoz пишет:

цитата:

Но это не есть универсальная структура.

Стремление к универсальности далеко не всегда оправдано. Если в текущей конкретной задаче подобная реализация не нужна, то и не стоит гнаться за этой универсальностью. Да и в принципе, не стоит пытаться угадывать, что именно пригодится в будущем. Это сложнее, чем угадать цену на Форексе. Поэтому лучший выход - делать то, что нужно в текущей задаче и ни грамма больше.

Приведенная структура вполне себе приличная, ничего крамольного в ней не вижу. Но это не значит, что пользоваться нужно только ею. К примеру, в моем текущем проекте нужно передавать данные об ордерах между компьютерами. У разных частей программы (клиент, интерфейсное звено, сервер) потребности в данных немного отличаются. В итоге каждая из них использует свою структуру хранения данных об ордерах, а интерфейсная часть преобразует один тип данных в другой. И ничего страшного. Главное - по сети не предается лишняя информация.
Вот серверная структура:

цитата:

struct ServerOrderInfo { int ticket; int fromTicket; // Если ордер образовался на основании встречного или частичного закрытия int orderType; int magic; datetime openTime; uchar symbol[24]; double openPrice; double slPrice; double tpPrice; double volume; };

Вот клиентская:

цитата:

struct ClientOrderInfo { int ticket; int fromTicket; // Если ордер образовался на основании встречного или частичного закрытия int orderType; datetime openTime; double openPrice; double slPrice; double tpPrice; double volume; string symbol; };

Как видно, клиентская часть не требует поля для записи Magic Number. Поэтому серверная структура оказалась избыточной, что привело к созданию нового типа данных. Также в серверной части необходимо было уйти от динамических элементов в структуре (string). В итоге имя символа записывается в массив char, который по сути принимает только 12 символов, а не 24 (string - это Юникод).