MQL dilinin sözdizimi için dilekler - sayfa 10

Yeni yorum
 
Tüm bunları okumak eğlenceli. MQL'ye sınıflar, "işaretçiler" ve yapılar getirmeye karar verdiklerinde eski yoldaşların çığlıklarını hatırlıyorum. Böylece şunu yazdılar: "MQL'yi öldürdünüz! Artık sadece profesyoneller üzerine yazabilir ..." - peki ve diğer saçmalıklar. Şimdi diğer taraftan çığlık atıyor: tam teşekküllü bir C ++ verin, aksi takdirde bir mega sistemi kodlamak imkansızdır. Ama hepinizi kim durduruyor? C++ al ve git. MQL biraz farklı bir hikaye ve sıcak ile uzunu karıştırmak bir şekilde naif.
 

C ++ hakkında ne diyorsun ... Pekala, C ++ sevmiyorsun, o yüzden C # al. Orijinal gönderide özellikle bahsetmiştim ve daha sonra tartışmalarda bunu vurguladım. Önerilenlerin çoğu her iki dil için de geçerlidir.

Dolayısıyla iki şeyden biri var: Ya prensipte ilerlemeye karşısınız ya da sadece homurdanıyorsunuz. Her iki seçenek de mümkün olsa da

 
Alexey Navoykov :

...

MetaTrader iyi bir terminaldir. Ancak ne yazık ki, kullanıcılarının büyük çoğunluğu ludomanyaklar ve kumarbazlar olarak kaldı. MQ, entelektüel ticaret alanına girmek için çok çaba sarf etti, ancak işe yaramadı. Kumarbazlar için MT4'ü çok renkli bir “TrendLaser” tablosuna koyarak “yırtmak” yeterlidir. Yapılar, sınıflar, decltype ile fırfırlar vb. umurlarında değil. Ama "ince bir koyun hatta bir tutam yün" ile - böyle yaşıyoruz. Bu nedenle mevcut durumda MQL5 dil araçlarını geliştirmek ekonomik olarak mümkün değildir. Kalabalıkla flört etmeniz önerilir, örneğin, MT5'te kilitlerin tanıtılması veya CopyRates yerine Open[0] görünümü.

 

Aslında, bu biraz garip. Başlangıçta MQL, ticaret stratejileri yazmak için uygulamalı bir dil olarak oluşturuldu. Bu nedenle, C++'daki her şey ona eklenmedi. Ve muhtemelen iyi. Ancak zamanla, algoritmik ticaretteki görevler daha karmaşık hale geldi ve insanlar dile eklemeler arıyor ve bekliyor. Bu nedenle, kasıtlı olarak eklenmeyen her şeyi içine koyma eğilimindedirler. Aynı zamanda, dilin kurallarının sayısı ve karmaşıklık düzeyi artacak ve onlar için bir engel haline gelecektir. Ancak üstesinden gelmeye hazırlarsa, onları durduramazsınız.

Benim için geliştirme, her şeyden önce bir fikri hayata geçirmenin en doğru ve basit yolunu bulmaktır. Buna dayanarak, eski dilin özellikleri oldukça yeterli, ancak profesyonel programcılar bir sürü kural ve bir yığın sözdizimi için nostaljik hissediyorlar. )) Peki, onlara ilham veriyorsa neden olmasın?

 
Реter Konow :

Aynı zamanda, dilin kurallarının sayısı ve karmaşıklık düzeyi artacak ve onlar için bir engel haline gelecektir.

O zaman neden bariyer? Yeni özelliklerin eklenmesi eskilerin kullanımını engellemez. Genelde. Bu nedenle, hiç kimse bu "zorlukları" kullanmaya zorlamaz.

Elbette, yerleşik kuralların aniden acımasızca C++'ı memnun etmek için yeniden çizildiği dönemler olmasına rağmen, ancak bu, dilin hızlı gelişiminin zamanıydı. Şimdi hemen hemen her şey zaten orada, küçük iyileştirmeler var.

 

Bu arada, geçen bir buçuk yılda, kişisel olarak sadece iyileştirme eksikliğini değil, aynı zamanda dilin yeteneklerinin de kısıtlandığını hissediyorum. En işlevsel ve istikrarlı yapı, 14 Mart 2017 tarihli 1554'tü. Ardından, iç kısımlarda bir tür temel değişiklik yapıldı ve bazıları bugüne kadar düzeltilmeyen bir dizi hata içeren sorunlu yapılar başladı. Doğru, bazı eski hatalar düzeltildi. Genel olarak, hata seviyesi açısından, mevcut yapılar muhtemelen biraz kazanır. Ama işlevselliğe gelince...

Örneğin, dizileri temel türlere dönüştürme yeteneğini azaltmak hakkında zaten yazmıştım. Bir diğer kesinti, basit yapıların birbirine getirilmesinin yasaklanmasıydı. Evet, karşılığında sendikalar verdiler, ancak standart işlevselliğin eksikliklerini gidermeyi mümkün kılan, dökümün verdiği olasılıkları kapsamıyorlar. Yani, yapıların polimorfizminin üretilmesine izin verdi. MQL'deki yapılar için arayüz eksikliğinden dolayı (ki zaten hakkında yazmıştım), bu çözüm iyi bir alternatifti. Bunun gibi:

 template < typename T>
struct IValueable
{ 
   double Value() const { return ((T) this ).GetValue(); }
 protected :
  IValueable() { }
 private :
   static void Check_IValueable() { T::Check_IValueable(); }   // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
   double _value;

  A( double value) { _value=value; }
  
   double GetValue() const { return _value; }
};


void Func(IValueable<A> &a) { Print (a.Value()); }


void OnStart ()
{
  A a( 10 );
  Func(a);
}
 
Alexey Navoykov :

O zaman neden bariyer? Yeni özellikler eklemek, eskilerin kullanımını engellemez. Genelde. Bu nedenle, hiç kimse bu "zorlukları" kullanmaya zorlamaz.

Elbette, yerleşik kuralların aniden acımasızca C++'ı memnun etmek için yeniden çizildiği dönemler olmasına rağmen, ancak bu, dilin hızlı gelişiminin zamanıydı. Şimdi hemen hemen her şey zaten orada, küçük iyileştirmeler var.

Demek istediğim, yeni kuralları ve sözdizimini kendi başına kullanmak isteyenler için bir engel. Programlarını daha uzun yazmak ve daha uzun anlamak zorunda kalacaklar. Bu onların programlarını daha etkili hale getirecek mi? - bir gerçek değil. Daha fazla sorunu çözebilecekler mi? - bir gerçek değil.

Bir kere forumda herkesin bir "dağ" koduyla çözdüğü bir soruna çok basit bir çözüm önerdim. Küçük ve hızlıydı. Ancak, herkes bundan hoşlanmadı. Sevdiklerine sahip değillerdi. Herhangi bir şablon < typename T> ve void Func(IValueable<A> &a)

Bunların hepsini kullanmam istendi. "Neden?" diye sorulduğunda kimse net bir şey açıklamadı.


PS Aldığım en net açıklama "Kodunuz çirkin". Ve yine: "Kavramsal gücü anlamıyorsunuz." Ama ben bir geliştiriciyim. Güzel bir çözüme ihtiyacım var, güzel koda değil.

 
Alexey Navoykov :

basit yapıları birbirine getirme yasağı. Evet, karşılığında sendikalar verdiler, ancak standart işlevselliğin eksikliklerini gidermeyi mümkün kılan, dökümün verdiği olasılıkları kapsamıyorlar. Yani, yapıların polimorfizminin üretilmesine izin verdi. MQL'deki yapılar için arayüz eksikliğinden dolayı (ki zaten hakkında yazmıştım), bu çözüm iyi bir alternatifti. Bunun gibi:

Derler

 #include <TypeToBytes.mqh>

template < typename T>
struct IValueable
{ 
   uchar Tmp;
   double Value() const { return (_C(T, this )).GetValue(); }
 protected :
//  IValueable() { }
 private :
   static void Check_IValueable() { T::Check_IValueable(); }   // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
   double _value;

//  A(double value) { _value=value; }
   void Set( double value ) { _value=value; }
  
   double GetValue() const { return _value; }
};

Ama sonuç tabii ki farklı.

1...345678910
Yeni yorum