Hatalar, hatalar, sorular - sayfa 2591

[Ilyas]

Koldun Zloy :

Ancak kopyalanan dizenin boyutu ayrılan arabelleğin boyutundan daha büyük veya daha küçükse ne olur?

Daha az endişelenecek bir şey değilse, kural olarak, dize arabelleği her zaman dizenin kendisinden biraz daha büyüktür (ancak bu bir gerçek değildir!)

Ancak daha fazlasını yazarsanız, terminalin çökmesi neredeyse kesindir.
Ve çökme büyük olasılıkla hemen olmayacak, ancak yalnızca dinamik bellekle (dizilerin veya dize arabelleklerinin yeniden dağıtılması) bir sonraki çalışma sırasında veya çalışmanın sonunda, MQL programlarının kullanılan belleği sisteme döndürüldüğünde

[Roman]

Ilyas :

1. MQL'de yalnızca unicode, bu nedenle karakter boyutu 2 bayttır

2. string bir yapıdır (4 bayt arabellek boyutu ve 8 bayt işaretçi)

Dize kopyala böyle olmalı

Bu işe yaramazsa, hata başka bir yerde aranmalıdır.

Evet, en basit işlev

wcscpy(out, data);

ve soruna neden olur. Çizgi düz kopyalanmış, ancak büyük boşluklar var. Bu, kopyalamada bir gecikmedir.
Bu nedenle, doğru kullanıldığında sorun yaratan başka işlevler de denenmiştir.
Herhangi bir mutex, recursive_mutex, lock_guard boşluk problemini çözmez.

Bu nedenle artık nereden düşüneceğimi bilemiyorum, tekrar ediyorum soketten gelen satır doğru geliyor,
sonuçtaki wchar_t* dizesinin türü otomatik olarak bunun Unicode kodlamasında olduğunu ve dizedeki her karakterin 2 bayta (işaretli) eşit olduğunu gösterir.
Ama bir şekilde wchar_t * sekiz bayt işaretçisinin on iki baytlık dizede doğru bir kopyası olacağı bana ulaşmıyor.
Belki işletim sisteminin bitliği hala bir şekilde onu etkiler? Her şey 64 bit sürümlerde, Windows ve Linux'ta test edilmiştir.

[Ilyas]

Boşlukların ne olduğundan emin değil misiniz? Boş satırlar?

Tüm dizilerden bir MQL dizisine mi yoksa farklı dizilere mi yazıyorsunuz?

MQL kodunda arka arkaya veri olduğuna ve bunların işlenebileceğine/gösterilebileceğine ne zaman karar veriyorsunuz?

Her şey tek satırdaysa ki bu yanlışsa, DLL tarafında MQL ve satır değiştirme sayacından erişilebilen kritik bir bölüme ihtiyacınız var.


MQL'den sahte kod

 #import ...
   bool LockValueIfChanged();
   void UnlockValue();
#import


while (!_IsStopped())
  {
   if (LockValueIfChanged())
     {
       Print ( Value );
      UnlockValue();
     }
  }

DLL

uint64_t last_mql_counter= 0 ;
uint64_t counter= 0 ;

bool LockValueIfChanged()
  {
   Lock(cs);

   if (last_mql_counter!=counter)
    {
     last_mql_counter=counter;
     return ( true );
    }

   Unlock(cs);
   return ( false );
  }

void UnlockValue()
  {
   Unlock(cs);
  }

Thread()
  {
   while ( running )
     {
      Lock(cs);

      Value = ...

      counter++;

      Unlock(cs);
     }
  }

Bu yaklaşık bir şemadır ve MQL tarafından satır boşlukları olacaktır (MQL'de tüm satırlar alınmayacak, bazılarının üzerine yazılacaktır)

[Roman]

Ilyas :

Boşlukların ne olduğundan emin değil misiniz? Boş satırlar mı?

Tüm dizilerden bir MQL dizisine mi yoksa farklı dizilere mi yazıyorsunuz?

MQL kodunda arka arkaya veri olduğuna ve bunların işlenebileceğine/gösterilebileceğine ne zaman karar veriyorsunuz?

Her şey tek satırdaysa ki bu yanlışsa, DLL tarafında MQL ve satır değiştirme sayacından erişilebilen kritik bir bölüme ihtiyacınız var.


MQL'den sahte kod

DLL

Bu yaklaşık bir şemadır ve MQL tarafından satır boşlukları olacaktır (MQL'de tüm satırlar alınmayacak, bazılarının üzerine yazılacaktır)

Evet, boş satırlar, ekranda görebilirsiniz.
Evet, tüm iş parçacıklarından bir MQL hattına. Anında bir dize için değişkenler oluşturmak da bir sorun olduğundan.
Hatların nereden geldiği, yani dinamik olarak ne kadar kaynak gireceği önceden bilinmiyorsa.
Ayrıca kritik bölümler için bir düşünce vardı, MQL tarafından bir şekilde okumayı engellemenin gerekli olduğunu da düşündüm. Örnek için teşekkürler, düşüneceğim.
Ama yine de dizenin her kaynağının kendi değişkeninde alınmasını önerdiğiniz ortaya çıktı? Ve tek bir MQL dize değişkenine değil.
Yalnızca bir dize değişkeninden, tüm iş parçacıklarından alınan verilerle çalışmak daha uygundur.
Dll tarafında bir yazma kilidi varsa, MQL okumasında bir kilit gerektirmediğini, yani MQL'de böyle bir kopyalama uygulamasının dikkate alındığını düşündüm.
Ancak bir akıştan bir dize alsanız bile, yine de boşluklar var!
Ve diğer kopyalama işlevlerini doğru parametrelerle kullanırsanız, boşluk yoktur, en az bir, en az birkaç akış vardır, ancak karakterlere göre düzensiz bir satır alırsınız.
Yanlış parametreleri kullanıyorsunuz, hat düz çıkıyor ama akmaya başlıyor.

[Koldun Zloy]

Ilyas :

Daha az endişelenecek bir şey değilse, kural olarak, dize arabelleği her zaman dizenin kendisinden biraz daha büyüktür (ancak bu bir gerçek değildir!)

Ancak daha fazlasını yazarsanız, terminalin çökmesi neredeyse kesindir.
Ve çökme büyük olasılıkla hemen olmayacak, ancak yalnızca dinamik bellekle (dizilerin veya dize arabelleklerinin yeniden dağıtılması) bir sonraki çalışma sırasında veya çalışmanın sonunda, MQL programlarının kullanılan belleği sisteme döndürüldüğünde

O zaman neden bir acemiye wcscpy işlevini kullanmasını tavsiye ediyorsun?

Daha güvenli işlevler de vardır: wcscpy_s, wmemcpy_s.

[Stanislav Korotky]

Lütfen OnCalculate işleyicisinde yeni oluşturulan her çubuk zamanının[0] zamanının neden SymbolInfoTick işlevini kullanarak talep ettiğimiz onay zamanından önce olduğunu açıklayın? Teoride, zaten bir zaman[0] çubuğu varsa, onu oluşturan bir onay işareti olmalıdır ve SymbolInfoTick işlevinin her zaman bilinen son onay işaretini döndürmesi gerekir.

Bu sorunu test cihazında tik-tik modunda yeniden oluşturan bir gösterge ekliyorum.

 2019.10 . 12 16 : 51 : 53.667 2019.01 . 02 06 : 00 : 00    Time 2019.01 . 02 06 : 00 : 00 = 1546408800000 is ahead of tick:   1546297199572
2019.10 . 12 16 : 51 : 53.753 2019.01 . 02 06 : 01 : 00    Time 2019.01 . 02 06 : 01 : 00 = 1546408860000 is ahead of tick:   1546408830000
2019.10 . 12 16 : 51 : 54.315 2019.01 . 02 06 : 02 : 00    Time 2019.01 . 02 06 : 02 : 00 = 1546408920000 is ahead of tick:   1546408919000
2019.10 . 12 16 : 51 : 54.617 2019.01 . 02 06 : 03 : 00    Time 2019.01 . 02 06 : 03 : 00 = 1546408980000 is ahead of tick:   1546408979000

Barların her sınırında bu sorun var.

not. Bu gösterge ayrıca başka bir sorunu gösterir: keneleri sayar ve belgelere göre OnCalculate'in tüm tikler için atlamadan çağrıldığına bakılırsa, tik hacmi her zaman tik sayacıyla eşleşmelidir, ancak bu her zaman böyle değildir.

[Slava]

Stanislav Korotky :

Lütfen OnCalculate işleyicisinde yeni oluşturulan her çubuk zamanının[0] zamanının neden SymbolInfoTick işlevini kullanarak talep ettiğimiz onay zamanından önce olduğunu açıklayın? Teoride, zaten bir zaman[0] çubuğu varsa, onu oluşturan bir onay işareti olmalıdır ve SymbolInfoTick işlevinin her zaman bilinen son onay işaretini döndürmesi gerekir.

Bu sorunu test cihazında tik-tik modunda yeniden oluşturan bir gösterge ekliyorum.

Barların her sınırında böyle bir sorun var.

not. Bu gösterge ayrıca başka bir sorunu gösterir: keneleri sayar ve belgelere göre OnCalculate'in tüm tikler için atlamadan çağrıldığına bakılırsa, tik hacmi her zaman tik sayacıyla eşleşmelidir, ancak bu her zaman böyle değildir.

yapı numarası lütfen

[Stanislav Korotky]

Slava :

yapı numarası lütfen

2093

[Slava]

Stanislav Korotky :

2093

Tanımladığınız sorun, yapı 2155'te düzeltildi.

[Artyom Trishkin]

Düzenleyicide vurgulanan sabit SYMBOL_CHART_MODE_OLD bulundu.

ENUM_SYMBOL_CHART_MODE 'da elbette öyle değil.

Bu ne?