![MQL5 - MetaTrader 5 müşteri terminalinde yerleşik ticaret stratejileri dili](https://c.mql5.com/i/registerlandings/logo-2.png)
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
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
...
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?
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:
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.
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
Ama sonuç tabii ki farklı.