Çaydanlıktan gelen sorular - sayfa 14

Yeni yorum
 

Burada düşünülmesi gereken başka bir şey var. Tamamladığınızdan emin olun! // Sonuçları rapor et. ;)

 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 :

Arkadaşlar açıkçası kafam karıştı. Düz bir zeminde yüzüyorsun. Kesinlikle eşit.

Sadece bu "ciddi" sohbete daldığım için özür dilemek istedim. Evet, sigara almaya giderken beni dövdüler.

Ve sonuçta "aptallar" değil mi? Ve böyle bir "boo-boo-boo" sıfırdan yakıldı.

CExpert sınıfında ulong için düzelteceğim.

 
Renat :

Hatalısınız.

Evet. Tür dönüştürmeyi unuttum.

 
uncleVic :

Ve sonuçta "çaydanlıklar" değil mi?

Ben birçok konuda çaydanlığım. Bu yüzden long döndürmek için tasarlanan işlevlerin ULONG_MAX-1'i nasıl döndüreceğini anlamıyorum. Tamsayı türleri ile yüzeysel çalışmanın tuzakları hakkında neredeyse El Kitabının kendisinde yazılmıştır. sergeev sorunun nedenini doğru bir şekilde yakaladı: sipariş kontrolü. request.magic öğesini ulong türünde ayarlarsam, HistoryDealGetInteger () , PositionGetInteger() , OrderGetInteger() işlevlerinin de ulong döndürmesini beklerim. Açık-örtük tür dönüşümleri olmadan.

Boş zamanımda MetaDriver'dan örnekleri analiz edeceğim. ...Ancak, verdiği örnekler long<->ulong türündeki (örneğin, double -> int'den farklı olarak) dönüştürmeler sırasında değer kaybı olmadığını açıklarsa, o zaman sonraki düşünce çizgisi netleşir.

amcaVic :

Ve böyle bir "boo-boo-boo" sıfırdan yakıldı.

Aslında, "Çaydanlıktan Sorular" konusu, kınama değil, açıklama elde etmek için seçilmiştir.

 
Yedelkin :

Ben birçok konuda çaydanlığım. Bu yüzden long döndürmek için tasarlanan işlevlerin ULONG_MAX-1'i nasıl döndüreceğini anlamıyorum. Tamsayı türleri ile yüzeysel çalışmanın tuzakları hakkında neredeyse El Kitabının kendisinde yazılmıştır. sergeev sorunun nedenini doğru bir şekilde yakaladı: sipariş kontrolü. request.magic öğesini ulong türünde ayarlarsam, HistoryDealGetInteger () , PositionGetInteger() , OrderGetInteger() işlevlerinin de ulong döndürmesini beklerim. Açık-örtük tür dönüşümleri olmadan.

Boş zamanımda MetaDriver'dan örnekleri analiz edeceğim. ...Ancak, verdiği örnekler long<->ulong türündeki (örneğin, double -> int'den farklı olarak) dönüştürmeler sırasında değer kaybı olmadığını açıklarsa, o zaman sonraki düşünce çizgisi netleşir.

Aslında, "Çaydanlıktan Sorular" dalı, sansür değil, açıklama elde etmek için seçilmiştir.

Gücenmiş? Üzgünüm, dayanamadım.
 
uncleVic :
Gücenmiş? Üzgünüm, dayanamadım.
Evet, hayır, internet savaşlarında sertleşme var. Ben sadece tartışmayı her zaman yapıcı bir yöne yönlendirmeye çalışırım, tabiri caizse.
 
sergeev :

Aslında, 64 değil, yalnızca 63 bit kullanılır (yani, eksik 8 bayt). 8 bayt, long aralığının tamamını kullanıyorsanız olacaktır.

Ama maalesef...

Bir yandan, MqlTradeRequest yapısına ulong büyüsü geçirilir. Bu, yalnızca pozitif değerlerin belirtilebileceği anlamına gelir.

Öte yandan, PositionGetInteger / OrderGetInteger işlevleri uzun bir tür döndürür . Bu, ulong aralığının yarısının kesildiği anlamına gelir.

Toplamda, beyan edilen 64 bit yerine, aslında 63 bitimiz var.Genel olarak, bu o kadar da kötü değil, çünkü sipariş kontrolü ilkelerine büyük rahatsızlık veriyor.

MT4'teki gibi benzer bir sistem bırakmak çok daha uygundur - işaretli büyülere izin verin. Birçok ticaret sistemi, sihirli işareti kullanarak basit bir prensip üzerine inşa edildiğinden. Bu nedenle, bir sistemi ikiye bölmek ve siparişlerinizi MathAbs( OrderMagicNumber() ) olağan işleviyle filtrelemek çok daha kolaydır.

hepsi 64. Aslında. İmzalı veya imzasız bir türe yapışmayın. Bu, derleyicinin doğru aritmetik işlemleri sağlaması içindir (pekala, bit düzeyinde sağa kaydırma, işarete bağlı olarak mantıksal veya aritmetik olabilir)

Verileri aktarırken (atarken) ve aynı boyuttaki imzalı-imzasız veri dökümünde, bilgiler hiçbir yerde kaybolmaz. ULONG_MAX'ı ileri geri yuvarlamayı deneyin. Uzun-ulong atamayı deneyin ve tam tersi. Yapıları kopyalamayı deneyin.

En iyisi kendin görmek. O zaman soru bir kez ve herkes için kapanacak.

 
MetaDriver :

İşte düşünmeniz gereken başka bir ipucu. Tamamladığınızdan emin olun! // Sonuçları rapor et. ;)

Tamamlandı! Şifrelemede 14. satırı Ll = 45488872996494496524 ile değiştirin

Genel olarak, bu sonuca vardım. MqlTradeRequest yapısının açıklamasından büyünün ulong tipinde olduğu sonucu çıkar, yani. LONG_MAX sabitinin değerinden daha büyük değerler atanabilir. Aynı zamanda ... GetInteger() gibi işlevler uzun türle çalışacak şekilde tasarlanmıştır, bu nedenle sihirli değerler bu işlevler tarafından örtük olarak uzun türe aktarılacaktır. Ancak long ve ulong türündeki değişkenler arasında bire bir yazışma olduğundan, magic değerini ... GetInteger() gibi işlevler tarafından döndürülen sonuçla karşılaştırırken, açık bir dökümü güvenle kullanabilirsiniz (örneğin: büyü == (ulong)OrderGetInteger(ORDER_MAGIC) ).

Tekrarlanan açıklayıcı örnekler için ATP.

 

stringo :

Verileri aktarırken (atarken) ve aynı boyuttaki imzalı-imzasız veri dökümünde, bilgiler hiçbir yerde kaybolmaz. ULONG_MAX'ı ileri geri yuvarlamayı deneyin. Uzun-ulong atamayı deneyin ve tam tersi. Yapıları kopyalamayı deneyin. Kendiniz görün ve efsaneleri yaymayın

Zaten denedim, tür zorlandığında istenen sonuç döndürülür (peki, belki biraz daha "teflerle dans etmek" ek olarak yapılmalıdır. Ama bu artık o kadar önemli değil).

amcaVic :

CExpert sınıfında ulong için düzelteceğim.

Bence iyi bir nokta, magick'te negatif değerler kullanan kişi, iade edilmesi/ayarlanması gerekenleri uygulamak zorunda kalacak.

Belgelerin yalnızca uzun veya ulong'u değil, bu türlerin her ikisini de (örneğin, "uzun / ulong") belirtmesi de çok iyi olurdu.

 
stringo :

Verileri aktarırken (atarken) ve aynı boyuttaki imzalı-imzasız veri dökümünde bilgi hiçbir yerde kaybolmaz.

Ek soru: çift -> uzun geçerken bilgi kaydetmenin zarif bir yolu var mı?
1...789101112131415161718192021...277
Yeni yorum