danışman projesi - sayfa 6
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Medeni bir dünyada, listeler aracılığıyla uygulanır...
MQL'de medeni bir kütüphane yazın, sonra konuşalım. Bu çığlıklar yıllardır duyuluyor ve iş bu noktaya gelir gelmez Frank bydlokoding başlıyor.
CObject MQ'daki referanslarla gerçekten berbattı. Orada olmamalılar. Ve bu bağlantılar CList gibi çok özel kaplarda kullanılır. Ama nerede hatalar var? Medeni dilleri konuşuyor musunuz? Aynı Richter'in eleştirisini, Nesne C # hakkında ne düşündüğünü ve onun görüşüne göre hangi yöntemlerin içinde olmaması gerektiğini okuyun. Öyleyse, Richter haklı olduğu için C# kullanmayı bırakmalı mıyız? Rave. Bu yüzden burada yığılmayı bırakın, sonunda prosedürel ormanınıza gidin.
Evet, sabit nesneleri bir listeye koyamazsınız.
Ancak aynı zamanda sürekli olarak CObject'in işlevselliğini kullanıyorum ve eleştirmenlerin hiçbiri Standart Kitaplığın nesnelere, dizilere ve listelere benzer bir şey önermedi bile.
"Nasıl yapılır" herkesin bağırma şeklidir. Ama bir şey teklif etmek için - ve ANINDA hiçbir şey yok.
Gerçekten çeşitli yazılım çözümleri sunan katılımcılar bile - CObject'y için yedek teklif sunmayan - onu daha sık kullanmazlar, işlevselliğini daha az kullanırlar, "tek bir yerden uygulamaya" dikkat etmezler. Yani - uygulama kendisi için oldukça uygundur.
Kötü olsaydı, uzun zaman önce bir değiştirme teklif ederdi.
Eh, genellikle normal CObject, diğer her şey aynı zamanda standart kitaplığı temel aldığında kullanılır. Özellikle kaynak kodunu aktif olarak paylaşanlar, genellikle üçüncü taraf kullanıcıların hayatını kolaylaştırmak için birleştirme, kendi yazdığı kodları azaltma ve kendi kitaplıklarının sayısını azaltma eğilimindedir. Ancak burada herkes kendisi için mi yoksa başkalarının rahatlığı için mi kodladığına kendisi karar verir.
Ve bu yüzden, birçok insanın (benim gibi) kendi çözümlerini kullandığına inanıyorum, sadece onları birine sunma gereğini görmüyorlar. Ama genel olarak, MFC gibi bazı iyi bilinen kütüphanelere dayanan bir standart olsaydı daha iyi olurdu diye düşünüyorum. Bu yüzden MQ'yu gerçekten anlamıyorum, neden hazır bir çözüm sunmak yerine kendi tekerleklerini (ve çok tartışmalı) icat etmek zorunda kaldılar. Ancak, MQL dilinin kendisi için de aynı şey söylenebilir))
Ancak prensipte kimseyi CObject'i terk etmeye zorlamadım, MQ'dan muhteşem bir CObject varsa, birinin neden CMyCobject kullandığını söyledikleri ifadesine cevaben eleştirel yorumumu yaptım :)
MQL'de medeni bir kütüphane yazın, sonra konuşalım. Bu çığlıklar yıllardır duyuluyor ve iş bu noktaya gelir gelmez Frank bydlokoding başlıyor.
Benim kitaplıklarım var. Peki ne hakkında konuşmak istedin?
CObject MQ'daki referanslarla gerçekten berbattı. Orada olmamalılar. Ve bu bağlantılar CList gibi çok özel kaplarda kullanılır. Ama nerede hatalar var? Medeni dilleri konuşuyor musunuz? Aynı Richter'in eleştirisini, Nesne C # hakkında ne düşündüğünü ve onun görüşüne göre hangi yöntemlerin içinde olmaması gerektiğini okuyun. Öyleyse, Richter haklı olduğu için C# kullanmayı bırakmalı mıyız? Rave. Bu yüzden burada yığılmayı bırakın, sonunda prosedürel ormanınıza gidin.
Daha az hırs ve ayrıca kabalık, seninle kişiselleşmedim.
"Bağlantılarla dolu" hakkında - evet, bu konuda her şeyi çizdikten sonra komik. Daha önce kelimenin tam anlamıyla CObject burada çizmiş olsanız da, bu çok harika ve işaretçiler bile varsayılan olarak orada başlatılmamış (en azından önce kodladığınız dili öğrenecekler). Genel olarak, burada önünüze boncuk atmak için daha fazla neden göremiyorum.
Ancak, katılıyorum, kullanmak her zaman gerekli olmaktan uzaktır OOP .
Diyelim ki bir sınıfım var CDataProvider:pulic CDataProviderI, EA'ya zaman serileri, göstergeler, terminal ve ortam verileri sağlayan bir veri sağlayıcısıdır. Expert Advisor içinde çok sayıda TS olabilir - her biri veri sağlayıcıdan zaman serilerine ve göstergelere yönelik işaretçiler alır (sonuç olarak, her bir TS'nin bu zaman serilerini oluşturmaya özen göstermesi gerekmez - veri sağlayıcı, gerekli zaman serileri, zaten varsa ve yalnızca henüz oluşturulmamış olanları yaratacaktır).
Bir veri sağlayıcıdan gösterge almanız gerektiğinde, gösterge açıklama yapısını doldurmanız ve ardından sağlayıcıdan bu yapıya işaret ederek göstergeyi talep etmeniz gerekir.
Buna göre, veri sağlayıcı içindeki her gösterge kendi yapısını tanıyabilmelidir (veri sağlayıcı yalnızca yapının soyut temel sınıfını "tanımıştır") ve onu kullanarak hazır bir gösterge nesnesi yaratabilmelidir - bu, veri sağlayıcı tarafından verilecektir.
Ancak, bir tür göstergenin yeni bir fikrini test etmek için tüm bu bahçeyi çitle çevirmek elbette mantıksız. Sonuç olarak - bu tür yeni göstergeler için - her şey herhangi bir OOP olmadan "diz üzerine monte edilir". Ancak, göstergenin Uzman Danışmanlar için yararlı olduğunu görürsem, "beklendiği gibi" yazılır - tam OOP desteği ve veri sağlayıcının içinde oluşturma.
yaklaşık 15 yıl önce, MT4'teki tüm göstergeleri ters pozisyon modunda alım satım için uygunluk açısından test ettiğimde, günde sadece 1 tane kar veren buldum. Göstergelerin çoğu yerleşik göstergeler temelinde oluşturulmuştur, sonuç olarak ticaretin etkinliği hemen hemen herkes için düşüktür. Tahminin doğruluğu veya modelin karlılığı için piyasayı incelemek, bence herhangi bir tüccarın ilk görevi. çevre ve işlevlerin tanımı, bu, zaten bulunan ve kâr sağlayan bir model üzerinde çalışırken rahatlık ihtiyacıdır.
Samimi olarak.
PS Ve her zaman eleştirmenler, ahmaklar, sadece trolleme sevenler olacak. asıl mesele, sizi gittiğiniz yönden alamamaları ve fikirlerinizin uygulanmasını görmemeleridir. Ne de olsa bütün bu sirkin görevi, kardan uzak, kafa karıştırıp yanlış yöne yönlendirmek.
Peki, neden kendi kendine yazılmış bir bisiklet değil de CObject kullanmanız gerektiği sorusunu kendiniz yanıtladınız. Bu, hayatı sadece başkaları için değil, her şeyden önce kendiniz için kolaylaştırmak için gereklidir, çünkü "birleştirme", "kendi kendine yazılan kodun azaltılması", "kendi kütüphanelerinin sayısında azalma" kelimeleri - her geliştiricinin yaptığı budur. için çaba sarf etmelidir. Bu, programcının kutsal kâsesidir.
Tabii ki, standart kütüphane modası geçmiş. Şimdi dil, jenerik yapmanıza izin veriyor ve şimdi arayüzler olacak. Ama eskisi işe yarıyor ve bu iyi bir birleşme ve dedikleri gibi en iyisi iyinin düşmanı. Çünkü bu en ideali ve en iyisi yok, iyiyi kullanmak lazım.
"Bağlantılarla dolu" hakkında - evet, bu konuda her şeyi çizdikten sonra komik. Daha önce burada kelimenin tam anlamıyla CObject üzerinde “çizip ** olup olmadığını”, bunun çok harika olduğunu ve işaretçilerin bile varsayılan olarak orada başlatılmadığını belirtmiş olsanız da (en azından, kodladığınız dil hakkında başlamak için donanım chtolünü öğrenmelisiniz). ). Genel olarak, burada önünüze boncuk atmak için daha fazla neden göremiyorum.
Burada kimse senin önünde secde etmeyecek. İnanın bana, burada hepimiz için "keşfettiğiniz" "kutsal" bilgi uzun zamandır birçok kişi tarafından biliniyor. Bağlantıların başlatılması hakkında tartışmayacağım bile. Resmi olarak haklı olduğunu biliyorsun, bu yüzden aynı şeye burnumu sokmaya çalışıyorsun: diyorlar ki, mat kısmını oku, NULL'un ne olduğunu öğren, vb. Ama benim öğretmem gerekmiyor. Havalısın. Herşeye sahipsin. Öyleyse neden önümüze boncuk atıyorsun? En iyisi;%:#%; kitaplığınıza. Görüyorsunuz, %0.5 daha hızlı kazanacak.
işlerinde aynı göstergeleri kullanan birçok araç için harika bir çözüm. ancak testler için uygun değildir ve bu nedenle dizinizin üzerine yazmanız gerekir.
yaklaşık 15 yıl önce, MT4'teki tüm göstergeleri ters pozisyon modunda alım satım için uygunluk açısından test ettiğimde, günde sadece 1 tane kar veren buldum. Göstergelerin çoğu yerleşik göstergeler temelinde oluşturulmuştur, sonuç olarak ticaretin etkinliği hemen hemen herkes için düşüktür. Tahminin doğruluğu veya modelin karlılığı için piyasayı incelemek, bence herhangi bir tüccarın ilk görevi. çevre ve işlevlerin tanımı, bu, zaten bulunan ve kâr sağlayan bir model üzerinde çalışırken rahatlık ihtiyacıdır.
Hayır, burada sadece göstergenin özüne doğru bir şekilde yaklaşmanız gerekiyor. Gösterge sizin için hazır bir Kâse değil, sadece fiyat hareketinin bazı özelliklerinin uygun bir ifadesidir. Buna göre, onlara yaklaşım kesinlikle "son sinyal kaynağı" olarak değil, sadece bir tür "sinyalin işareti" olarak olmalı ve bunları bir arada kullanmalıdır. Ve bu durumda, çoğu testte birçok gösterge gerekli olmaya başlar. Özellikle, diyelim ki, ATR - Neredeyse her yerde kullandığım için şablona bir Expert Advisor'ı standart olarak yerleştirmeyi düşünüyorum. Aynı Mashki de oldukça sık gerekli göstergelerdir. Fraktallar, pinbar göstergeleri...
...
Ancak, katılıyorum, kullanmak her zaman gerekli olmaktan uzaktır OOP .
Diyelim ki bir sınıfım var CDataProvider:pulic CDataProviderI, EA'ya zaman serileri, göstergeler, terminal ve ortam verileri sağlayan bir veri sağlayıcısıdır. Expert Advisor içinde çok sayıda TS olabilir - her biri veri sağlayıcıdan zaman serilerine ve göstergelere yönelik işaretçiler alır (sonuç olarak, her bir TS'nin bu zaman serilerini oluşturmaya özen göstermesi gerekmez - veri sağlayıcı, gerekli zaman serileri, zaten varsa ve yalnızca henüz oluşturulmamış olanları yaratacaktır).
Bir veri sağlayıcıdan gösterge almanız gerektiğinde, gösterge açıklama yapısını doldurmanız ve ardından sağlayıcıdan bu yapıya işaret ederek göstergeyi talep etmeniz gerekir.
Buna göre, veri sağlayıcı içindeki her gösterge kendi yapısını tanıyabilmelidir (veri sağlayıcı yalnızca yapının soyut temel sınıfını "tanımıştır") ve onu kullanarak hazır bir gösterge nesnesi yaratabilmelidir - bu, veri sağlayıcı tarafından verilecektir.
Ancak, bir tür göstergenin yeni bir fikrini test etmek için tüm bu bahçeyi çitle çevirmek elbette mantıksız. Sonuç olarak - bu tür yeni göstergeler için - her şey herhangi bir OOP olmadan "diz üzerine monte edilir". Ancak, göstergenin Uzman Danışmanlar için yararlı olduğunu görürsem, "beklendiği gibi" yazılır - tam OOP desteği ve veri sağlayıcının içinde oluşturma.
not
Bu arada, göstergeler ve bir veri sağlayıcı durumunda, miras sanallaştırmadaki avantaj açıkça görülmektedir. Temel bir gösterge parametreleri arayüzümüz var CIndicatorParametersI, bu arayüzün halefi gerekli göstergenin gerçek parametreleridir. Bir gösterge talep ederken, bu parametreleri bildiririz ve veri sağlayıcıya soyut arayüze bir işaretçi iletiriz. Bu nedenle, veri sağlayıcının kendisi hangi göstergenin talep edildiğini bile bilmiyor - bu, göstergenin ihtiyaç duyulan türden yeni tarafından oluşturulduğu bir işlevde belirlenir. Ve tam olarak hangi parametrelerin iletildiği hakkında - yalnızca bu oluşturulan gösterge bilir, bu da geçen nesneden gerekli parametreleri çıkarır.
İşin püf noktası, veri sağlayıcının içinde hemen hemen her yerde, basit bir temel parametre sınıfı (veya göstergeler) ile iş yapılmasıdır - veri sağlayıcısı için yalnızca temel arabirimlerin en basit ve en yaygın işlevleri kullanılabilir. Bu, kodun değiştirilmesini basitleştirir (gerektiğinde) ve veri sağlayıcıdan gösterge kodunu "girmek" için bir ayartma yaratmaz. Bir göstergeyi değiştirmeniz gerekiyorsa, bu yalnızca göstergenin kendi içinde yapılır, veri sağlayıcı yalnızca bir gösterge deposu iken, yapabileceği maksimum şey yeni bir gösterge oluşturmaktır.
İşimi zorlaştırıyorsun. Veri sağlayıcı MetaTrader'ın kendisidir. Onlar. Gerçekten bir hak düzenleyicisine ihtiyacınız yok, sadece verilerle çalışmak için kullanıcı dostu bir arayüze ihtiyacınız var. Örneğin, benim lib'imde, çalışan bir enstrümanın son çubuğunu açmanın fiyatını almak için şunu yazmanız yeterlidir:
WS nesnesi her zaman oradadır ve her zaman elinizin altında ve çalışır durumdadır. Bunu nasıl yaptığı perde arkasında gizlidir. Tüm veri erişimi bu kadar :)
ps OOP, sistemi kullanmanın karmaşıklığını azaltmalı, artırmamalıdır. Ve basit bir kontrol uğruna bahçeyi çitle çevirmeniz gerektiğini kendiniz kabul ederseniz, mimarinizde sağlayıcı ile ilgili bir sorun var. Onlar. Her zaman kullanmak istemediğiniz bir şeyi programladınız.Hayır, burada sadece göstergenin özüne doğru bir şekilde yaklaşmanız gerekiyor. Gösterge sizin için hazır bir Kâse değil, sadece fiyat hareketinin bazı özelliklerinin uygun bir ifadesidir. Buna göre, onlara yaklaşım, "nihai sinyal kaynağı" olarak değil, sadece bir tür "sinyalin işareti" olarak olmalı ve bunları bir arada kullanmalıdır. Ve bu durumda, çoğu testte birçok gösterge gerekli olmaya başlar. Özellikle, diyelim ki, ATR - Neredeyse her yerde kullandığım için şablona bir Expert Advisor'ı standart olarak yerleştirmeyi düşünüyorum. Aynı Mashki de oldukça sık gerekli göstergelerdir. Fraktallar, pinbar göstergeleri...
Geri dönüş göstergesinin sinyali üzerine "sürekli piyasada" modunda çalışmaktan bahsediyordum ve 15 yıl önce tekrar ediyorum, şimdi piyasa vizyonum biraz değişti.
Samimi olarak.
İşimi zorlaştırıyorsun. Veri sağlayıcı MetaTrader'ın kendisidir. Onlar. Gerçekten bir hak düzenleyicisine ihtiyacınız yok, sadece verilerle çalışmak için kullanıcı dostu bir arayüze ihtiyacınız var. Örneğin, benim lib'imde, çalışan bir enstrümanın son çubuğunu açmanın fiyatını almak için şunu yazmanız yeterlidir:
WS nesnesi her zaman oradadır ve her zaman elinizin altında ve çalışır durumdadır. Bunu nasıl yaptığı perde arkasında gizlidir. Tüm veri erişimi bu kadar :)
ps OOP, sistemi kullanmanın karmaşıklığını azaltmalı, artırmamalıdır. Ve basit bir kontrol uğruna bahçeyi çitle çevirmeniz gerektiğini kendiniz kabul ederseniz, mimarinizde sağlayıcı ile ilgili bir sorun var. Onlar. Her zaman kullanmak istemediğiniz bir şeyi programladınız.(Diyelim ki "siz") girişiniz "WS. [ 0 ] açın ;" "m_tcMainContainer.Open(0)" girişimden çok az farklı
WS nesnesinin başlatılmasında bazı ön adımlar olması gerektiğinden şüpheleniyorum.
Benim durumumda, bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer)işlevini çağırmak gerekiyor.
Expert Advisor'ın her bir bölümünde (giriş oluşturucuda, takip eden ve çıkış kontrolörlerinde - yani alım satım işlemlerini gerçekleştirebilen nesnelerde) bir "Timeseries Container" nesnem var - aslında, OHLCSTVtVr zaman serisine ek olarak bir işaretçidir. hizmet yetenekleri.
Bir Expert Advisor'da farklı sembollerden ve farklı zaman dilimlerinden oluşan birçok farklı kap olabilir. Veri sağlayıcının ideolojisi, onları kopyalamamanıza izin verir. Gerçek olduğu için - tüm zaman serileri içinde saklanır ve kaplar sadece gerekli olanları gösterir.
Pek bir fark görmüyorum - anladığım kadarıyla WS (muhtemelen WareStore?) hala benim veri sağlayıcım. Sadece diğer veriler de veri sağlayıcımda yoğunlaşıyor - göstergeler, semboller (CSymbolInfo nesneleri), ayrıca bir çizelge koleksiyonuna sahip terminal (CTerminalInfo nesnesi). Her yenilemede zaman serisi güncellenir (gerektiği gibi) - burada ideoloji, Standart Kitaplığın ideolojisine yakındır.
MT4-5'in kendisini bir veri sağlayıcı olarak kabul edersek ve sınıfımızı yalnızca erişim sağlamak için kullanırsak, o zaman, Açık fiyata olan itirazınıza göre, tek bir değer için CopyOpen() işlevini çağırmalıyız - öyle görünüyor ki bana mantıksız
Ayrıca programın herhangi bir yerindeki tüm değişkenlere tam global erişim vermeyi son derece mantıksız buluyorum, aksine programın her yerinden sadece bu işlem için gerekli olan yapılara ve verilere erişmeye çalışıyorum. Diğer her şey kullanılamaz olmalıdır. Veri sağlayıcının ideolojisi sadece bu erişimi kontrol etmenize izin verir.
ATP'yi bir gösterge olarak görmüyorum, belirli bir süre için ortalama piyasa oynaklığını gösteriyor, çünkü giriş sinyali uygun değil (filtre olarak kullanılabilir, daha fazla değil). Maşalar, ters pozisyon modunda negatif kar verir. fraktallar da. Pinbar göstergesi yerleşik değildir.
Geri dönüş göstergesinin sinyali üzerine "sürekli piyasada" modunda çalışmaktan bahsediyordum ve 15 yıl önce tekrar ediyorum, şimdi piyasa vizyonum biraz değişti.
Samimi olarak.
Yani "ATR gösterge sayılmaz" nasıl oluyor ???
Ve nasıl "giriş için bir sinyal olarak iyi değil ??? Ve ben bir aptalım, sadece bu göstergeyi kullanarak "volatilite dökümü" girişini kullanıyorum...
Göstergelerin özüne ilişkin kendi özel anlayışınıza sahip olduğunuzdan şüpheleniyorum... Benim için gösterge, zamana bağlı olarak bazı değişken değerler üretebilen bir nesnedir. Aslında, normal bir şamdan fiyat tablosu bile bir göstergedir. Ama senin için başka bir şey... Buna göre anlayışımız farklı.