Вопросы от "чайника" - страница 14

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

Вот ещё фишечка на подумать.  Выполнить обязательно!  // О результатах доложить. ;)

struct s_char8
  {
   char c[8];
  };
struct s_long
  {
   long l;
  };
void OnStart()
  {
    Print("//------ ");
    
    s_long L;
    L.l = 2387159478511726799;

    s_char8 Ch = L;

    string S = CharArrayToString(Ch.c, 0);
    
    Print(S);
   }
 
MetaDriver:

Мужики, я честно в недоуменьях.  Вы паритесь на ровном месте. Абсолютно ровном.

Только я хотел извинившись вклинится в этот "серьёзный" разговор. Да пока  ходил за сигаретами, меня опередили.

И вроде ведь не "чайники"? А такое "бу-бу-бу" развели на пустом месте.

В классе CExpert поправлю на ulong.

 
Renat:

Вы ошибаетесь.

да. про преобразование типов забыл.

 
uncleVic:

И вроде ведь не "чайники"?

Я - чайник по многим вопросам. Поэтому не понимаю, как функции, предназначенные возвращать long, будут возвращать ULONG_MAX-1. О подводных камнях поверхностной работы с целочисленными типами пишется чуть ли не в самом Справочнике. sergeev правильно уловил причину возникновения вопроса: контроль ордеров. Если я задаю request.magic типа ulong, то ожидаю, что функции HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() будут возвращать тоже тип ulong. Без каких-либо явно-неявных преобразований типов.

Примеры от MetaDriver разберу на досуге. ...Впрочем, если его примеры будут разъяснять, что при преобразованиях типа long<->ulong не происходит потери значений (в отличие от, например, double -> int), то  дальнейший ход мысли становится понятен.

uncleVic:

А такое "бу-бу-бу" развели на пустом месте.

 Вообще-то ветка "Вопросы от "чайника" была выбрана с целью получения разъяснений, а не порицаний.

 
Yedelkin:

Я - чайник по многим вопросам. Поэтому не понимаю, как функции, предназначенные возвращать long, будут возвращать ULONG_MAX-1. О подводных камнях поверхностной работы с целочисленными типами пишется чуть ли не в самом Справочнике. sergeev правильно уловил причину возникновения вопроса: контроль ордеров. Если я задаю request.magic типа ulong, то ожидаю, что функции HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() будут возвращать тоже тип ulong. Без каких-либо явно-неявных преобразований типов.

Примеры от MetaDriver разберу на досуге. ...Впрочем, если его примеры будут разъяснять, что при преобразованиях типа long<->ulong не происходит потери значений (в отличие от, например, double -> int), то  дальнейший ход мысли становится понятен.

 Вообще-то ветка "Вопросы от "чайника" была выбрана с целью получения разъяснений, а не порицаний.

Обиделся? Извини, не сдержался.
 
uncleVic:
Обиделся? Извини, не сдержался.
Да не, закалка в интернет-боях имеется. Просто всегда стараюсь направить обсуждение в конструктивное русло, так сказать.
 
sergeev:

На самом деле используется не 64 а всего 63 бита ( то есть неполные 8 байт). 8 байт было бы, если использовать весь диапазон long.

Но к сожалению...

С одной стороны в структуру MqlTradeRequest передаётся ulong magic. Это означает, что задавать можно только положительные значения.

С другой стороны функции PositionGetInteger/OrderGetInteger возвращают тип long. Это означает, что половина диапазона ulong отсекается.

Итого вместо заявленных 64 бит имеем по факту 63. В общем-то, это не столько плохо - сколько привносит большие неудобства в принципы контроля ордеров.

Намного удобнее оставить аналогичную систему как в МТ4 - разрешить магики со знаком. Так как много торговых систем построено на простом принципе с использованием именно знака магика. Так ведь намного проще разделить одну систему на две и отфильтровывать свои ордера обычной функцией MathAbs( OrderMagicNumber() )

 

все 64. По факту. Не цепляйтесь к типу знаковому или беззнаковому. Это - для компилятора, чтобы обеспечить правильные арифметические операции (ну ещё побитовый сдвиг вправо бывает логический или арифметический, в зависимости от знаковости)

При передаче (присвоении) данных, а также при знаковом-беззнаковом кастинге данных одинакового размера, информация никуда не теряется. Попробуйте откастить ULONG_MAX туда-сюда. Попробуйте присвоение long-ulong и обратно. Попробуйте копирование структур.

Самое лучшее - это убедиться самому. Тогда вопрос закроется раз и навсегда.

 
MetaDriver:

Вот ещё фишечка на подумать.  Выполнить обязательно!  // О результатах доложить. ;)

 

Выполнено! В шифровке заменить 14-ю строчку на L.l = 4548887299649496524

В общем, пришёл к такому выводу. Из описания структуры   MqlTradeRequest следует, что magic отнесён к типу ulong, т.е. ему можно приписывать значения больше, чем значение константы LONG_MAX. При этом функции типа  ...GetInteger() предназначены для работы с типом long, поэтому значения magic будут неявно приводится этими функциями к типу long. Но поскольку существует взаимно-однозначное соответствие между переменными типов long и ulong, при сравнении значения magic с результатом, возвращаемым функциями типа  ...GetInteger(), можно спокойно использовать явное приведение типов (например: magic == (ulong)OrderGetInteger(ORDER_MAGIC) ).

Спс за неоднократные показательные примеры.

 

stringo:

При передаче (присвоении) данных, а также при знаковом-беззнаковом кастинге данных одинакового размера, информация никуда не теряется. Попробуйте откастить ULONG_MAX туда-сюда. Попробуйте присвоение long-ulong и обратно. Попробуйте копирование структур. Убедитесь сами и не распространяйте мифы

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

uncleVic:

В классе CExpert поправлю на ulong.

Хорошая мысль на мой взгляд, тому кто использует отрицательные значения в магике придется принудительно указывать что требуется вернуть/установить.

Еще бы было очень хорошо если бы в документации указали не просто long или ulong, а оба этих тип (например так "long / ulong").

 
stringo:

При передаче (присвоении) данных, а также при знаковом-беззнаковом кастинге данных одинакового размера, информация никуда не теряется.

Дополнительный вопрос: а есть ли какой-нибудь элегантный способ сохранить информацию при передаче double -> long?
1...789101112131415161718192021...278
Новый комментарий
Причина обращения: