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
George Merts
Стандартный CObject - это "объект списка или сортированного массива". CMyObject - это CObject, имеющий определенный тип, и содержащий некоторое значение, данное при его создании. Этот объект мне понадобился всвязи с повсеместным приведением объектов к базовому абстрактному классу - чтобы понимать по указателю, на какой именно объект "на самом деле" указывает. Тип CMyObject - устанавливается как раз той самой функцией SetMyObjectType(). Эта функция в обязательном порядке вызывается в конструкторах любых наследников от CMyObject, чтобы назначить идентификатор класса, к которому принадлежит создаваемый объект.
Yapıcınız açık ve parametrelendirilmemiş:
Bu, halefin türünü ayarlayabileceği veya ayarlayamayacağı anlamına gelir. Onlar. halefin içinde SetMyObjectType yöntemini çağırmayı unutursanız - boşa yazın.
Ne yapılabilir?
1. Oluşturucuyu dışarıdan oluşturmadan kapatın:
Ardından, yalnızca CTradeHistoryI soyundan gelen bir örnek oluşturabilecektir, bu da MOT_TRADE_HISTORY_I türüne olan ihtiyacın ortadan kalkacağı anlamına gelir. MOT_TRADE_HISTORY_I türünün hiçbir zaman gerçekte var olmadığına dikkat edin, çünkü CTradeHistoryI bir arabirimdir ve bu türle somutlaştırılamaz. Onlar. yapıcıyı kapatarak çelişkiyi çözeriz - var olmayan bir türün tanımı .
2. Örnekleme anında açık yazma gereksinimini ayarlayın:
İşte bu, artık hiçbir çocuk açık bir tip ataması olmadan kendini yaratamaz.
Standart ve anlaşılır bir CObject varken neden tekerleği CMyObject biçiminde yeniden icat edelim?
MQL'nin CObject'inde ne kadar iyi bulduğunuzu bilmiyorum. Her nesneye doldurulmuş iki gereksiz işaretçi = 16 bayt kayıp + bellek tahsis edilirken ve bu işaretçiler başlatılırken fazladan ek yük. OOP'nin kendisi performansı yavaşlatır ve eğer böyle aptalca kararlar varsa...
Önce OOP'yi öğrenin, sonra tartışırız. Başlatma m_prev, m_next bu durumda genellikle oluşmaz.
Önce OOP'yi öğrenin, sonra tartışırız. Başlatma m_prev, m_next bu durumda genellikle oluşmaz.
Sadece senden sonra.
Ve böylece bilgi için, işaretçilerin MQL'de başlatılması her zaman gerçekleştirilir.
Yapıcınız açık ve parametrelendirilmemiş:
Bu, halefin türünü ayarlayabileceği veya ayarlayamayacağı anlamına gelir. Onlar. halefin içinde SetMyObjectType yöntemini çağırmayı unutursanız - boşa yazın.
Ne yapılabilir?
...
Evet, gerçekten de bazı durumlarda SetMyObjectType() öğesini belirtmeyi unutuyorum - ve nesneler varsayılan CMyObject türüyle oluşturuluyor.
Ve çözüm iyi.
Teklifler kabul edilir.
Yine de, korumalı kurucuyu sevmiyorum.
Evet, gerçekten de bazı durumlarda SetMyObjectType() öğesini belirtmeyi unutuyorum - ve nesneler varsayılan CMyObject türüyle oluşturuluyor.
Ve çözüm iyi.
Teklifler kabul edilir.
Yine de, korumalı kurucuyu sevmiyorum.
Korumalı bir kurucu, yalnızca böyle bir kurucuya sahip bir ebeveynden doğrudan miras alan sınıflar için hayatı zorlaştırır. Ancak kullanıcı düzeyinde, düşünmeden ve özgürce türetilmiş nesneler oluşturabilirsiniz.
Bu nedenle, rahatsızlık gözlenmemelidir.
MQL'de başka seçenek yok çünkü tip kontrol sistemi yoktur, daha doğrusu öyledir, ancak az gelişmiş bir formdadır, bu nedenle yapıcıyı gizleyerek türü korumanız gerekir.
MQL'nin CObject'inde ne kadar iyi bulduğunuzu bilmiyorum. Her nesneye doldurulmuş iki gereksiz işaretçi = 16 bayt kayıp + bellek tahsis edilirken ve bu işaretçiler başlatılırken fazladan ek yük. OOP'nin kendisi performansı yavaşlatır ve eğer böyle aptalca kararlar varsa...
Neden "aptal"? Bana göre ek yük çok küçük ve CObject'in listeleri ve sıralı dizileri düzenlemek için sağladığı rahatlığa kesinlikle değer.
Mikrosaniye ve baytları kovalamamız gerekiyorsa, o zaman, elbette, bu "kayıp baytların" çok fazla kaynaktan sorumlu olup olmadığını anlamak mantıklıdır. Ancak uygulamamın gösterdiği gibi, kod yazmanın ve korumanın rahatlığı çok daha önemlidir.
Bu arada, son zamanlarda kod optimizasyonu ile uğraşıyordum - Uzman Danışmanlarım bir şekilde test cihazında çok yavaş çalıştı. En yavaş işlev veri yenilemedeydi. Buna göre, bu yenilemenin çekiciliğini azaltmak için her şekilde denedim. Ancak, son zamanlarda test cihazında kodun profilini çıkarmak mümkün hale geldi. Ve benim için büyük bir sürpriz olarak, EA'nın zamanının çoğunu (neredeyse) gereksiz bir işlevle benim için son durum talep etme işleviyle harcadığını gördüm (her yenilemede gerçekleştirildi ve basitçe "aynı anda" yapıldı). diğerleri). Ve en önemlisi - boş hafıza talep etme işlevi için harcandı. Terminal durumunun başlangıçta yalnızca bir kez ve ardından yenilemeler sırasında - yalnızca açıkça belirtildiğinde - istenmesi için kodda yapılan küçük bir değişiklik, testi üç kattan fazla hızlandırdı!
Bu nedenle, "gereksiz ek yük", onu aradığımız yerde hiç kaybolmayabilir.
Bu nedenle, "gereksiz ek yük", onu aradığımız yerde hiç kaybolmayabilir.
Neden "aptal"? Bana göre ek yük çok küçük ve CObject'in listeleri ve sıralı dizileri düzenlemek için sağladığı rahatlığa kesinlikle değer.
Bu "kolaylıklar" tek bir yerde uygulanır. Bu, nesnelerinizdeki bir şeyi değiştiren ne tür bir liste? Nitekim, sabit nesnelerin listeye yerleştirilemeyeceği ortaya çıktı. Veya böyle bir listede bulunan nesnenizi belirli bir işleve gönderdiğiniz ve onu da listesine koyduğunuzu ve ardından nesnenizi önceki ve sonraki değiştirilmiş olarak geri aldığınız ve yola çıktığınızı hayal edin ...
Uygar dünyada listeler, gerekli işaretçileri depolayan yardımcı Düğüm nesneleri aracılığıyla uygulanır. Ve kullanıcının nesnelerine dokunmak saçmalık. Yani mesele sadece genel giderde değil, tüm bunların temel yanlışlığında. Geliştiriciler aceleyle bir şeyi kör etti ve böyle olması gerektiğine seviniyorsunuz.
Bu "kolaylıklar" tek bir yerde uygulanır. Bu, nesnelerinizdeki bir şeyi değiştiren ne tür bir liste? Nitekim, sabit nesnelerin listeye yerleştirilemeyeceği ortaya çıktı. Ya da böyle bir listede bulunan nesnenizi belirli bir fonksiyona gönderdiğiniz ve onu da onun listesine koyduğunuzu ve ardından nesnenizi önceki ve sonraki değiştirilmiş olarak geri aldığınız ve yola çıktığınızı hayal edin...
Uygar dünyada listeler, gerekli işaretçileri depolayan yardımcı Düğüm nesneleri aracılığıyla uygulanır. Ve kullanıcının nesnelerine dokunmak saçmalık. Yani mesele sadece genel giderde değil, tüm bunların temel yanlışlığında. Geliştiriciler aceleyle bir şeyi kör etti ve böyle olması gerektiğine seviniyorsunuz.
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.