Форум » Консультации по программированию » Реализация структуры данных для мультивалютника » Ответить
Реализация структуры данных для мультивалютника
hoz: Когда я писал свои коды, я предвидел, что придётся когда-нить переписывать их с уклоном на мультивалютник. На данный момент меня интересуют некоторые моменты. Начну с структуры: 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-мерного массива наверное. Первое измерения массива будет - индекс торгуемого инструмента, а второе его характеристика. Возможно ещё какие-то варианты есть, но я пока что не придумал. Как это лучше реализовать? Я не совсем представляю.
Ответов - 1
Scriptong: 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 - это Юникод).
полная версия страницы