찻주전자의 질문 - 페이지 13

 
stringo :

실제로 매직용으로 8바이트 정도의 정보가 주어지는데, 마음대로 해석할 수 있다. 최소 datetime, 최소 double, 최소 4 short, 최소 8 char, 최소 64비트 비트.

4바이트에서는 4바이트의 마법으로 무엇이든 인코딩할 수 있었고 이제는 8바이트로 늘어났습니다. 욕망이 있을 것입니다.

그리고 이것은 이해할 수 있습니다. 나는 4에서 그것을 잘 사용 하고 기사를 읽었습니다 (나는 그 아이디어가 정말 좋았습니다).

명확하지 않습니다. 왜 다른 장소에 다른 유형이 표시됩니까?

 

가격이 예를 들어 TP에서 멀지 않고 지금 엑시트해야 하는 경우 설정된 TP 및 SL 로 포지션을 청산할 수 있는 방법을 알려주십시오.

볼륨이 동일한 새 위치를 열도록 명령을 보냅니다. 대부분의 경우 이것이 작동합니다. 그러나 거래가 TP에 의해 마감될 시간이 있고 마감하는 대신 시장에서 새로운 포지션을 얻는 상황이 있습니다... :(

개설되는 포지션이 기존 포지션의 청산을 의미하고 메인 포지션이 이미 청산된 경우 새 포지션을 열지 않는다는 것을 어떻게 나타낼 수 있습니까?

"닫기 전에 SL과 TP를 제거하거나 TP가 완료될 때까지 기다리십시오"와 같은 옵션이 생각나지만 이러한 솔루션은 보기 흉합니다. MT4에서와 같이 CLOSE와 같은 간단한 작업을 수행하는 것이 실제로 불가능합니까 ???

 

CTrade 클래스에서 PositionClose 를 참조하십시오.
나는 그것이 당신과 같을 것이라고 확신합니다. 하나의 결론이 스스로 제안합니다. 지금은 다른 방법이 없습니다.

그러나 나는 당신의 요청을 지지합니다. 그리고 개발자들에게 이 옵션을 고려해 달라고 요청합니다.

작업 유형 TRADE_ACTION_CLOSE 추가 - 현재 가격 으로 해당 거래량에서 지정된 상품의 포지션을 청산합니다.

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
stringo :

실제로 매직용으로 8바이트 정도의 정보가 주어지는데, 마음대로 해석할 수 있다. 최소 datetime, 최소 double, 최소 4 short, 최소 8 char, 최소 64비트 비트.

4바이트에서는 4바이트의 마법으로 무엇이든 인코딩할 수 있었고 이제는 8바이트로 늘어났습니다. 욕망이 있을 것입니다.

디렉토리에서 long 및 ulong에 대해 약 8바이트가 지워졌습니다. 마법과 관련하여 이러한 유형을 사용하는 데 있어 일관성이 없다는 것은 놀라운 일입니다.

간단한 예: 거래 요청을 보낼 때 request.magic= ULONG_MAX-1을 할당하는 것이 허용됩니다. 그렇다면 핸드북에서는 OrderGetInteger( ORDER_MAGIC ) 함수가 긴 유형만 반환한다고 명시하는 이유는 무엇입니까? 또한 위치와 거래 모두에 대해 long 유형의 매직도 반환됩니다.

그럼 원래 의도는 어땠나요? HistoryDealGetInteger() , PositionGetInteger() , OrderGetInteger() 등의 함수가 있으므로 struct MqlTradeRequest 에 대해 매직이 long 유형임을 지정해야 할 수도 있습니다. LONG_MAX보다 큰 정수 값을 반환하도록 의도되지 않았습니까?

 
Yedelkin :

디렉토리에서 long 및 ulong에 대해 약 8바이트가 지워졌습니다. 마법과 관련하여 이러한 유형을 사용하는 데 있어 일관성이 없다는 것은 놀라운 일입니다.

간단한 예: 거래 요청을 보낼 때 request.magic= ULONG_MAX-1을 할당하는 것이 허용됩니다. 그렇다면 핸드북에서는 OrderGetInteger( ORDER_MAGIC ) 함수가 긴 유형만 반환한다고 명시하는 이유는 무엇입니까? 또한 위치와 거래 모두에 대해 long 유형의 매직도 반환됩니다.

그럼 원래 의도는 어땠나요? HistoryDealGetInteger() , PositionGetInteger() , OrderGetInteger() 등의 함수가 있기 때문에 struct MqlTradeRequest 에 대해 매직이 long 유형임을 지정해야 할 수도 있습니다. LONG_MAX보다 큰 정수 값을 반환하도록 의도되지 않았습니까?

매직은 실제로 long 유형입니다(이는 long 유형 의 값 범위를 벗어난 값과 음수 매직 및 매직을 생성하여 쉽게 검증됩니다 ).

검증을 위해 Night Expert Advisor를 약간 수정할 수 있습니다(표준 라이브러리의 클래스를 사용하지 않음).

실험의 순수성을 위해 EA_Magic 매개변수의 유형을 long 으로 변경하고 이력의 마지막 거래의 마법을 인쇄해야 합니다(주문이 성공적으로 이루어진 경우).


 

Interesting :
В действительности магик имеет тип long (это легко проверяется формированием отрицательного магика и магика со значением выходящим за диапазон значений типа long ).

그렇다면 유형 이름에서 문자 " u "를 제거하여 MqlTradeRequest 구조의 매직 요소에 대한 설명을 명확히 해야 합니다.
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура торгового запроса
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура торгового запроса
  • www.mql5.com
Стандартные константы, перечисления и структуры / Структуры данных / Структура торгового запроса - Документация по MQL5
 
Yedelkin :
그렇다면 유형 이름에서 문자 " u "를 제거하여 MqlTradeRequest 구조의 매직 요소에 대한 설명을 명확히 해야 합니다.
좋은 점은 CTrade 클래스도 변경해야 한다는 것입니다(물론 개발자가 매직 값을 양수 값으로 제한하려는 경우 제외).
 
stringo :

실제로 매직용으로 8바이트 정도의 정보가 주어지는데, 마음대로 해석할 수 있다. 최소 datetime, 최소 double, 최소 4 short, 최소 8 char, 최소 64비트 비트.

4바이트에서는 4바이트의 마법으로 무엇이든 인코딩할 수 있었고 이제는 8바이트로 늘어났습니다. 욕망이 있을 것입니다.

실제로는 64비트가 아니라 63비트만 사용된다(즉, 불완전한 8바이트). long 의 전체 범위를 사용하는 경우 8바이트가 됩니다.

하지만 안타깝게도...

한편으로는 ulong 마법이 MqlTradeRequest 구조로 전달됩니다. 이것은 양수 값만 지정할 수 있음을 의미합니다.

반면 PositionGetInteger / OrderGetInteger 함수 유형 을 반환합니다 . 즉, ulong 범위의 절반이 잘립니다.

전체적으로 선언된 64비트 대신 실제로는 63비트가 있는데, 일반적으로 이것은 순서 제어의 원칙에 큰 불편 을 줄 정도로 나쁘지 않습니다.

MT4와 유사한 시스템을 유지하는 것이 훨씬 더 편리합니다. 기호로 마법을 허용하십시오. 많은 거래 시스템이 마술 기호를 사용하는 간단한 원리에 따라 구축되기 때문입니다. 따라서 하나의 시스템을 두 개로 나누고 일반적인 함수 MathAbs( OrderMagicNumber() ) 를 사용하여 주문을 필터링하는 것이 훨씬 쉽습니다.


 
sergeev :

실제로는 64비트가 아니라 63비트만 사용된다(즉, 불완전한 8바이트). long 의 전체 범위를 사용하는 경우 8바이트가 됩니다.

당신은 잘못.

64비트가 사용되며 어떻게 사용할지는 사용자에게 달려 있습니다. long/ulong은 중요하지 않으며 모두 해당 64비트를 해석하는 방법에 따라 다릅니다. 부호 있는 long으로 사용하려면 사용하고 unsigned ulong으로 사용하려면 문제 없이 사용하십시오. 다른 데이터 유형을 이 64비트로 압축하려면 압축하십시오.

그것이 Slava가 쓴 것입니다.

 
sergeev :

실제로는 64비트가 아니라 63비트만 사용된다(즉, 불완전한 8바이트). long 의 전체 범위를 사용하는 경우 8바이트가 됩니다.

하지만 안타깝게도...

한편으로는 ulong 마법이 MqlTradeRequest 구조로 전달됩니다. 이것은 양수 값만 지정할 수 있음을 의미합니다.

반면 PositionGetInteger / OrderGetInteger 함수 유형 을 반환합니다 . 즉, ulong 범위의 절반이 잘립니다.

전체적으로 선언된 64비트 대신 실제로는 63비트가 있는데, 일반적으로 이것은 순서 제어의 원칙에 큰 불편 을 줄 정도로 나쁘지 않습니다.

MT4와 유사한 시스템을 유지하는 것이 훨씬 더 편리합니다. 기호로 마법을 허용하십시오. 많은 거래 시스템이 마술 기호를 사용하는 간단한 원리에 따라 구축되기 때문입니다. 따라서 하나의 시스템을 두 개로 나누고 일반적인 함수 MathAbs( OrderMagicNumber() ) 를 사용하여 주문을 필터링하는 것이 훨씬 쉽습니다.

여러분, 저는 솔직히 혼란스럽습니다. 당신은 평평한 땅에 떠 있습니다. 절대적으로 균일합니다. 문제는 단순히 존재하지 않습니다. 당신이 그것을 발명했습니다. 유형 변환의 맨 아래로 이동합니다.

아래 스 니펫이 도움이되기를 바랍니다. 스크립트에 복사해서 컴파일하고, 반드시 터미널에서 실행하고, 신중하게 생각해보세요. 행운을 빕니다.

 void OnStart ()
  {
     Print ( "//------ " );

     int i_A = - 100 ;
     uint ui_B = uint (- 100 );
    
     Print (i_A, " " , uint (i_A));
     Print ( int (ui_B), " " ,ui_B);

    i_A = int ( 4294967196 );
    ui_B = 4294967196 ;

     Print (i_A, " " , uint (i_A));
     Print ( int (ui_B), " " ,ui_B);
//--
     long l_A = - 100 ;
     ulong ul_B = ulong (- 100 );
    
     Print (l_A, " " , ulong (l_A));
     Print ( long (ul_B), " " ,ul_B);
   
    l_A = long ( 18446744073709551516 );
    ul_B = 18446744073709551516 ;
    
     Print (l_A, " " , ulong (l_A));
     Print ( long (ul_B), " " ,ul_B);
  }