Mql5 dilinin özellikleri, incelikleri ve çalışma yöntemleri - sayfa 102

 
Alexey Navoykov :

Eh, zaten çok ileri gittin) Önce mesaj kuyruğundan geçer. İkincisi, bazı ek dönüşümler (ileri geri) yapmanız gerekir. Ayrıca bir çeşit doğrulama oluyor.

Bu arada,yapının boyutu açıkça belirtilmemelidir. Sizeof bunun için var.

  • Mesaj kuyruğunu nerede gördün?
  • Gidiş dönüş dönüşümü yoktur. @fxsaber örneğinde olduğu gibi aynı birleşim kullanılmış
  • doğrulama da yok.
  • Elbette sizeof(...) kullanabilirsiniz, ancak o zamandan beri evrensel değil, belirli bir görevin uygulanmasıydı, o zaman 3 basamak şeklinde yazmak daha kısaydı.

Belki başka bir koda baktınız.

Sürümümde sevmediğim tek şey tehdit: dizenin sonu olarak sıfır alınır. Omuriliğimle daha kolay bir çözüm olduğunu hissediyorum ama bulamadım. Ama yine de daha hızlı çalışıyor.

 
Nikolay Semko :

  • Mesaj kuyruğunu nerede gördün?

SetWindowText/GetWindowText mesajlar yoluyla gönderilemedi mi?


Gidiş dönüş dönüşümü yoktur.

Tabii ki. Ve teflerle ne tür danslar:

 for ( int i= 0 ; i< 56 ; i++) if (U.a[i]== 0 ) m[ 2 *i+ 1 ]= 2 ; else m[ 2 *i]=U.a[i];
 
Alexey Navoykov :

SetWindowText/GetWindowText mesajlar yoluyla gönderilemedi mi?

Ve sen Windows mesajları hakkında ... Ne olmuş yani? Kendi kendine yazılan dll'ler olmadan Windows'ta farklı programlar arasında veri alışverişi için daha hızlı bir alternatif var mı?

Sözlerimden incindiğini anlıyorum, versiyonum akıllı. İlk olarak, bunu iddia etmedim, sadece varsaydım. İkincisi, varsayımımı Memory Mapping ile karşılaştırıldığında test koduyla destekledim.
Ve siz, bir varsayımı bile çürütmeye çalışıyorsanız, lütfen çürütmenizi yalnızca beyan edici ifadeler üzerine inşa etmeyin. Beni vazgeçirirseniz ve kendi kendine yazılmış dll'ler olmadan terminaller arasında daha hızlı bir veri alışverişi uygulamasına işaret ederseniz size çok minnettar olacağım.

RAM diski üzerinden seçeneğin çok daha hızlı olacağını ekarte etmiyorum. Ancak bu biraz farklı bir konudur, çünkü bu RAM diskinin yüklenmesini ve yapılandırmasını gerektirir.

Alexey Navoykov :

Tabii ki. Ve teflerle ne tür danslar:

 for ( int i= 0 ; i< 56 ; i++) if (U.a[i]== 0 ) m[ 2 *i+ 1 ]= 2 ; else m[ 2 *i]=U.a[i];

Onlar da benim için tef buldular. Bu banallik. Ve bu arada, bu önemsizlik, kene yapısını elde etmek için tüm blok 90 μs'de (90.000 ns) tamamlandığında 50-60 ns'de tamamlanır, yani bu "elmaslar" zamanın yalnızca %0.06'sını alır. veri bloğu. Ayrıca, bu anın sadece hafızamın iki katına çıkması nedeniyle kafamı karıştırdığını yazdım .

Ve bu yüzden benim sürümüm, küçük veri yapılarını değiştirmek için çok kullanışlı, basit ve akıllı görünüyor.

 
Nikolay Semko :

  • Sürümümde sevmediğim tek şey tehdit: dizenin sonu olarak sıfır alınır. Omuriliğimle daha kolay bir çözüm olduğunu hissediyorum ama bulamadım. Ama yine de daha hızlı çalışıyor.

Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum

Kitaplıklar: GeçmişTicks

Otomatik Ticaret , 2018.03.29 11:09

  • Kaynaklar, bir dizeye/dizeden herhangi bir veri koymanıza/almanıza izin veren çapraz platform işlevleri ( Data_String.mqh dosyası) içerir. Örneğin, bu , kullanıcı olaylarının dize parametresini (sparam) kullanarak herhangi bir MQL programı arasında uygun bir şekilde rastgele veri alışverişini mümkün kılar;
 #include <fxsaber\HistoryTicks\Data_String.mqh> // https://www.mql5.com/ru/code/20298

void OnStart ()
{
   MqlTick Tick;
  
   if ( SymbolInfoTick ( _Symbol , Tick))
  {
     const string Str = DATA_STRING::ToString(Tick);
    
     MqlTick Ticks[ 1 ];
    
    Ticks[ 0 ] = DATA_STRING::FromString< MqlTick >(Str);
     ArrayPrint (Ticks);
  }
}
 
fxsaber :

Vay!
CryptEncode ve CryptDecode gibi işlevleri bile bilmiyordum. Teşekkür ederim!
Çalışacağım.
PS Ancak şimdiye kadar, ilk bakışta, bunların hepsi, elbette, yüksek teknoloji, ancak delice yavaş, çünkü CryptEncode işlevi, burada tef olarak adlandırılandan iki büyüklük sırası daha yavaş (mikrosaniyeye karşı onlarca nanosaniye) yürütülür:

 for ( int i= 0 ; i< 56 ; i++) if (U.a[i]== 0 ) m[ 2 *i+ 1 ]= 2 ; else m[ 2 *i]=U.a[i];
 
Nikolay Semko :

Sözlerimden incindiğini anlıyorum, versiyonum akıllı. İlk olarak, bunu iddia etmedim, sadece varsaydım. İkincisi, varsayımımı Memory Mapping ile karşılaştırıldığında test koduyla destekledim.

Evet, "çevik" değilim, ama " mevcut tüm çözümlerden daha hızlı olması mümkündür " hakkında. Bu nedenle, herhangi bir baskın yapmadan birkaç yorum yaptım. Ve bu sözler oldukça haklıydı. Sadece bir nedenden dolayı ilk başta inatla inkar ediyorsunuz ("muhtemelen başka bir koda baktınız" ) ve sonra "ne olmuş!" konumuna geliyorsunuz. Öyleyse yine de sinekleri pirzolalardan ayıralım.

İlk olarak, benim gönderim, test kodunuzu göndermeden önce yazılmıştır. İkincisi, MemoryMapping (veya daha doğrusu, bahsedilen MQL sarmalayıcısı) ile ilgili olarak, hiçbir yerde hızlı çalıştığını iddia etmedim. Ayrıca buradaki bu projenin tartışma başlığında yazarın frenleri oluşturan hatalarına ve bunların nasıl düzeltileceğine dikkat çektim. Bu nedenle, zaten bir şeyi test etmeyi taahhüt ettiyseniz, onu yerel bir biçimde test edin , başkasının yanlış kararları şeklinde değil.

 
Nikolay Semko :

PS Ancak şimdiye kadar, ilk bakışta, bunların hepsi, elbette, yüksek teknoloji, ancak delice yavaş, çünkü CryptEncode işlevi, burada tef olarak adlandırılandan iki büyüklük sırası daha yavaş (mikrosaniyeye karşı onlarca nanosaniye) yürütülür:

Hız ne için?

 
Alexey Navoykov :

Evet, "çevik" değilim, ama " mevcut tüm çözümlerden daha hızlı olması mümkündür " hakkında. Bu nedenle, herhangi bir baskın yapmadan birkaç yorum yaptım. Ve bu sözler oldukça haklıydı. Sadece bir nedenden dolayı ilk başta inatla inkar ediyorsunuz ("muhtemelen başka bir koda baktınız" ) ve sonra "ne olmuş!" konumuna geliyorsunuz. Öyleyse yine de sinekleri pirzolalardan ayıralım.

İlk olarak, test kodunuzu göndermeden önce mesajım yazılmıştır. İkincisi, MemoryMapping (veya daha doğrusu, bahsedilen MQL sarmalayıcısı) ile ilgili olarak, hiçbir yerde hızlı çalıştığını iddia etmedim. Ayrıca buradaki bu projenin tartışma başlığında yazarın frenleri oluşturan hatalarına ve bunların nasıl düzeltileceğine dikkat çektim. Bu nedenle, zaten bir şeyi test etmeyi taahhüt ettiyseniz, onu yerel bir biçimde test edin , başkasının yanlış kararları şeklinde değil.

TAMAM. Kabul. Çok yüksek sesle söyledi.

Sadece, WinAPI kullanarak iki terminali birbirine bağlamaya gelince, kernel32.dll yerine user32.dll kullanmanın daha hızlı olabileceğini söylemek istedim. tanıştığım tüm uygulamalar kernel32.dll kullanıyordu.

 
fxsaber :

Hız ne için?

Üzgünüm, soruyu anlamadım.
Soruyorsunuz - terminaller arasındaki köprünün veri değişim oranı için ne gerekiyor?

 
Nikolay Semko :

Üzgünüm, soruyu anlamadım.
Soruyorsunuz - neden terminaller arasındaki köprünün veri değişim oranına ihtiyacımız var?

Evet.

Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum

Mql5 dilinin özellikleri, incelikleri ve çalışma yöntemleri

Nikolai Semko , 2018.09.21 13:20

PS Ancak şimdiye kadar, ilk bakışta, bunların hepsi, elbette, yüksek teknoloji, ancak delice yavaş, çünkü CryptEncode işlevi, burada tef olarak adlandırılandan iki büyüklük sırası daha yavaş ( mikrosaniyeye karşı onlarca nanosaniye ) yürütülür: