Birçokları için ilginç bir konu: MetaTrader 4 ve MQL4'te neler olacak - büyük değişiklikler yolda - sayfa 9
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
Madem piyasaya dokunduk, bir konuda görüş almak istiyorum...
MQL5 felsefesine göre, göstergeler sayılmalı ve Uzman Danışmanlar ticaret yapmalıdır.
Ancak pazar, dedikleri gibi, hepsi bir arada hazır çözümler satıyor.
Derleyici, göstergeler Uzman Danışmanlarda kaynak olarak depolanacak şekilde değiştirilebilir mi?
Aksi takdirde uygun ortamın olmadığı durumlarda gösterge kodunu Expert Advisor'a aktarmanız gerekir. Yine "göstergeden indikatör" şeması ile kodun bir Expert Advisor'a aktarılması zaten tam bir destandır.
Desteklerim
Şimdi başka bir sekme eklemenin pazar için yararlı olacağını düşünüyorum - örneğin setleri, talimatları vb. koyabileceğiniz DOSYALAR,
yine de - Tartışma sekmesi böyle bir fırsat veriyor, ancak yine de değil.
Derleyici, göstergeler Uzman Danışmanlarda kaynak olarak depolanacak şekilde değiştirilebilir mi?
Aksi takdirde uygun ortamın olmadığı durumlarda gösterge kodunu Expert Advisor'a aktarmanız gerekir. Yine "göstergeden indikatör" şeması ile kodun bir Expert Advisor'a aktarılması zaten tam bir destandır.
24 Kasım 2012 tarihli MetaTrader 5 Client Terminal build 730 haberlerine bakın
8. MQL5: Göstergeleri EX5 kaynaklarında saklamak için destek eklendi. Aynı zamanda kaynaklardaki göstergeler kendi kaynakları ile çalışamayacaklardır.
24 Kasım 2012 tarihli MetaTrader 5 Client Terminal build 730 haberlerine bakın
Ben de öyle yapıyorum. Ve danışmana (sunucudan gerçek olanın yerine) özel bir geçmiş gönderebilen sınıflar zaten benim için yazılmıştır. Ancak fikrin tam olarak uygulanması için danışman terminal işlevlerini doğrudan kullanmamalıdır. Aynı OrderSend() diyelim. Yalnızca , Standart Kitaplığın mükemmel bir şekilde uyduğu rolünde bir tür "sarmalayıcı" aracılığıyla çalışmalıdır. Türetilmiş sınıfları yazıyoruz, bunları Expert Advisor'a aktarıyoruz ve - işte - artık geçmiş veriler üzerinde çalışıyor. Danışman doğrudan terminal işlevlerini kullanıyorsa, üzerine bir hikaye kaydıramazsınız.
Görünüşe göre, çok memnun olduğum ve birçok paralellik bulduğum MFC kütüphanesi ile yaptığım uzun çalışma beni etkiliyor. Standart Kitaplığın geliştiricilerinin de MFC'ye oldukça aşina olduğundan eminim.
Standart Kitaplığın ana artısı, gerekirse, danışmanın herhangi bir değişiklik yapmadan oldukça normal çalışması için danışmana özel bir geçmiş aktarmanıza izin veren OOP ideolojisi için iyi bir destektir.
Ve Standart Kitaplıktan neyi sevmediğinizi sorabilirsiniz (bariz eksi hariç - "öğrenmek için çok tembel")?
Böyle bir eksi yok, Güvenlik Konseyi'ni çok iyi tanıyorum ve bu bilgi her şeyin ne kadar hantal ve verimsiz olduğunu anlamamızı sağlıyor.
Sipariş göndermek yerine, büyükanne dede için, dede şalgam için başlar.
Ancak (Ticaret tarafından) ana dezavantaj, yürütme kontrolünün tamamen yok olmasıdır. Siparişi sunucuya çarptı ve en azından çimler büyümedi. Ama Send'i tüm durumlar için olduğu gibi 10 şekilde sardılar ve 100 vaka vardı.
İdeolojiye göre: 2 nesilden fazla mirası bir hata olarak görüyorum, o zaman hem anlayış hem de esneklik kaybolur.
Sınıfların çoğu (haklısınız) icat edilmedi, ancak MFC ile aptalca kesintiye uğradı, bu daha büyük olasılıkla bir eksi değil, tekerleği neden yeniden icat edin.
Ama bence asıl dezavantajı ona güvenmenin mümkün olmaması, üzerine bir şeyler yazarsın ve kesinleşir :)
SB ile ve SB olmadan yazdım. Onsuz daha hızlı ve daha şeffaf çıkıyor. Çok yönlü, virajlarda çok beceriksiz.
Örneğin Delphi'de ortak derleme anlamına gelen proje kavramı vardır. Ve programların 3 türe bölünmesi genel olarak biraz şüphelidir, çünkü teoride derleyicinin kendisi programın ne yaptığını belirleyebilir, ancak göstergelerin yalnızca zorla takas edilmesi çok yaygın olduğu için ve bir danışman için gömmek gerekir. kod içeri, o zaman sadece geliştiricilerin kalbinin bir gün eriyeceğini ve proje yapmanıza izin vereceğini umabiliriz).
Desteklerim
Şimdi başka bir sekme eklemenin pazar için yararlı olacağını düşünüyorum - örneğin setleri, talimatları vb. koyabileceğiniz DOSYALAR,
yine de - Tartışma sekmesi böyle bir fırsat veriyor, ancak yine de değil.
24 Kasım 2012 tarihli MetaTrader 5 Client Terminal build 730 haberlerine bakın
Harika, bunu nasıl kaçırmışım, ahhh bunlar Yeni Yıl yapımları.
Gönderinizdeki üstü çizili, zaten yapabilecekleri anlamına mı geliyor?
Böyle bir eksi yok, Güvenlik Konseyi'ni çok iyi tanıyorum ve bu bilgi her şeyin ne kadar hantal ve verimsiz olduğunu anlamamızı sağlıyor.
Detaylı cevap için teşekkürler. Tüm ifadelerinize kategorik bir itirazım yok. Yani... bazı notlar...
Sipariş göndermek yerine, büyükanne dede için, dede şalgam için başlar.
Ancak bu tam olarak sisteme esneklik kazandıran şeydir ve tam da bu nedenle özel geçmişi ve sunucu öykünmesini danışmana aktarabiliyoruz. Siparişler doğrudan OrderSend() aracılığıyla gönderilseydi - aynı "büyükbaba için büyükanne, şalgam için büyükbaba" yazmanız gerekirdi ... Hangisinin daha iyi olduğu belli değil ...
Ancak (Ticaret tarafından) ana dezavantaj, yürütme kontrolünün tamamen yok olmasıdır. Siparişi sunucuya çarptı ve en azından çimler büyümedi. Ama Send'i tüm durumlar için olduğu gibi 10 şekilde sardılar ve 100 vaka vardı.
Burada yeterince tecrübem yok. Şimdilik sadece teori üretebilirim. İade kodlarının analizi - Hala kendim yapıyorum, ancak çok az iş deneyimi var. Güvenlik Konseyi'nde yürütme denetiminin tek başına yeterli olmadığı konusunda hemfikirim.
İdeolojiye göre: 2 nesilden fazla mirası bir hata olarak görüyorum, o zaman hem anlayış hem de esneklik kaybolur.
Evet, gerçekten de çok derin bir mirasın anlama üzerinde çok olumsuz bir etkisi vardır. Ama esneklik konusunda - kabul etmekte zorlanıyorum. 4-5 kuşaktan beri bir çok kalıtım vakası var ve herhangi bir sorun yaratmıyor gibi görünüyor. Ama benim için böyle olduğu konusunda hemfikir olabilirim, başkaları için belki de böyle bir miras derinliği büyük ölçüde engel oluyor.
Ama bence asıl dezavantajı ona güvenmenin mümkün olmaması, üzerine bir şeyler yazarsın ve kesinleşir :)
Burada - evet, tamamen katılıyorum.
SB ile ve SB olmadan yazdım. Onsuz daha hızlı ve daha şeffaf çıkıyor. Çok yönlü, virajlarda çok beceriksiz.
SB'yi tam olarak bir TS şablonu oluşturma olasılığıyla ve gelecekte - ona yalnızca girdileri, eşlikleri ve çıktıları tanımlayan nesne sınıflarını bağlayarak sevdim. Korkarım ki Güvenlik Konseyi olmadan, böyle bir ideoloji aynı, sadece Kendi Güvenlik Konseyi'nin yaratılmasına yol açacaktır.
"Daha hızlı ve daha şeffaf" gelince - bana öyle geliyor ki, herhangi bir aracı bir bütün olarak ele aldığımızda böyle bir ideoloji iyidir. Ancak bana öyle geliyor ki bu algoritmik ticarette ciddi bir hata. TS, yalnızca bir "küp" kompleksi olarak düşünülmelidir - bir dizi giriş üreteci, bir giriş TP-SL belirleyicisi, bir giriş lotu belirleyicisi, bir takip eden kontrolör vb. TS'nin "daha hızlı ve daha şeffaf" olduğu yüzlerce farklı varyantı alıyoruz.
Diyelim ki şablonsuz beş farklı TS yazdıktan sonra altıncıyı yazmak için bu beş sistemden parçalar kullansak bile her şeyi yeniden yazmamız gerekiyor. Şablonu yazdıktan sonra, bu beş sistemi içine sadece parçalar halinde çekeceğiz ve sonuç olarak beş adede kadar girdi oluşturucuya, girdi filtrelerine, TP-SL belirleyicilerine vb. sahip olacağız. Bunları birleştirerek, en istikrarlı ve karlı olanları seçebileceğiniz yüzlerce aracı kolayca elde ediyoruz.
Bu nedenle, bence Güvenlik Konseyi'nin tembelliği gerçekten de "iki ucu keskin bir kılıç"tır ve kullanılıp kullanılmayacağına her durumda ayrı ayrı karar verilmelidir.
Harika, bunu nasıl kaçırmışım, ahhh bunlar Yeni Yıl yapımları.
Gönderinizdeki üstü çizili, zaten yapabilecekleri anlamına mı geliyor?
Harika, bunu nasıl kaçırmışım, ahhh bunlar Yeni Yıl yapımları.
Burada tartışıldı: https://www.mql5.com/en/forum/3409#comment_408123