Birçokları için ilginç bir konu: MetaTrader 4 ve MQL4'te neler olacak - büyük değişiklikler yolda - sayfa 10
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
Bir çok küçük işlevi birleştiren çok iyi bir inliner'ımız olduğunu unutmayın, bu nedenle hız kaybı olmaz.
Ayrıca, çoğu durumda, vtable aracılığıyla sanal işlevlere yapılan çağrılar, doğrudan çağrılara dönüştürülür. Bu, etkili optimize edici yöntemlerinden biridir. Bu, çoklu satır içi ile birleştiğinde, karmaşık çok seviyeli aramalardan neredeyse tamamen kurtulmanıza ve kodu düz bir görünüme dönüştürmenize olanak tanır.
Bir çok küçük işlevi birleştiren çok iyi bir inliner'ımız olduğunu unutmayın, bu nedenle hız kaybı olmaz.
Ayrıca, çoğu durumda, vtable aracılığıyla sanal işlevlere yapılan çağrılar, doğrudan çağrılara dönüştürülür. Bu, etkili optimize edici yöntemlerinden biridir. Bu, çoklu satır içi ile birleştiğinde, karmaşık çok seviyeli aramalardan neredeyse tamamen kurtulmanıza ve kodu düz bir görünüme dönüştürmenize olanak tanır.
:) gülümsedi. Ve hiç kimse derleyicinin kodu mükemmel bir şekilde optimize ettiğini iddia etmiyor, ben sadece arkadaşıma neden SB'nin önünde secde etmediğim fikrini getiriyorum.
Tamam, birkaç örnek verelim:
pratikte basit bir standart fonksiyon ile değiştirilir
CopyBuffer (...);
Sanat için sanatımız var. Ve böylece, bir şey yapan her öğe için (anladığınız gibi geri kalanı, son öğelerin çalışması için yazılmıştır).
Evet, evrenselliğe katılıyorum, evet iyi yapılandırılmış koda katılıyorum (çalışma için bir örnek diyebilirsiniz).
Ve nokta nedir? Sonuç olarak, bu kitaplık öncelikle "MQL5 Sihirbazı" için ve OOP üzerine bir ders kitabı olarak ihtiyaç duyulmaktadır.
Arkadaşıma Güvenlik Konseyi'nin önünde neden secde etmediğim fikrini getiriyorum.
Evet, evet, bir kez daha vurgulayacağım - hiçbir argümanınıza ciddi bir itirazım yok. Bu konudaki tartışma nesnel olmaktan çok dini olacaktır.
Burada, sadece kendi örneğinizde, kişisel olarak BENİM için ve BENİM DURUMDA, kodun ilk sürümü, tam olarak göstergenin evrenselliğini ve tüm arayüzlerle uyumluluğunu sağlayan tüm bu çok seviyeli eklemeler nedeniyle daha kabul edilebilir görünüyor. CObject'a ve CiCustom'om ile biten. Bu nesne, bu seviyelerden biriyle nasıl çalışacağını bilen herhangi bir kullanıcıya iletilebilir ve ek bir çaba gerektirmez.
Ancak diğer yandan, tüm zaman serilerim ve göstergelerim istek üzerine oluşturulur, tek bir koleksiyona sığdırılır ve ardından tüm kullanıcılar tarafından kullanılabilir. Ve arabelleği BİR KEZ kopyalamanız gerektiğinde - soru ortaya çıkıyor - bahçeyi çitle ne için?
Yani basit bir durumda - CopyBuffer() kullanmak kesinlikle çok daha kolay olacaktır.
Peki ya bu arabelleğin bir düzine kullanıcımız varsa? Benim durumumda, hepsi arabellek için başvuracak, ilk istekte arabellek oluşturulacak ve diğer herkes ona bir bağlantı alacak. Ve eğer CopyBuffer() "alnında" kullanırsak - o zaman bir yerine on kopyamız olur. CopyBuffer()'ın daha incelikli bir kullanımıyla, kime ve hangi arabellek tahsis edildiğinin kaydını tutmanın faydasını görüyoruz, ki bunlar bahsettiğiniz kapsülleme maliyetine oldukça eşdeğerdir.
Şahsen ben rasyonellikten yanayım. Bir yer için, bir bahçeyi OOP ile çitlemek mantıklı değil. Çok sayıda kullanıcımız varsa, bence OOP yaklaşımı kendini haklı çıkarır.
Ardından, bir kodun hem mql4 hem de mql5 altında derlenebilmesi için istisnalar sunmanın zamanı geldi.
BE olarak birleşme sorunu demleniyor.
Burada iki dili birleştirirken #ifdef gibi koşullu derleme yönergelerinin kesinlikle gerekli olduğu düşünüldü - bu, iki platform arasındaki kodların birleştirilmesini büyük ölçüde kolaylaştıracak ve platforma bağlı API, derleme aşamasında belirlendi.
Ne yazık ki hayır. Test cihazı , MQL5 Cloud Network olmadan tek iş parçacıklı kalacaktır.
Bir çok küçük işlevi birleştiren çok iyi bir inliner'ımız olduğunu unutmayın, bu nedenle hız kaybı olmaz.
Ayrıca, çoğu durumda, vtable aracılığıyla sanal işlevlere yapılan çağrılar, doğrudan çağrılara optimize edilir. Bu, etkili optimize edici yöntemlerinden biridir. Bu, çoklu satır içi ile birleştiğinde, karmaşık çok seviyeli aramalardan neredeyse tamamen kurtulmanıza ve kodu düz bir görünüme dönüştürmenize olanak tanır.
Ahhh... Şimdi neden program yazarken en sık yaptığım hatalardan birinin "Fonksiyonun bir gövdesi olmalı" olduğunu anlıyorum.
Bu inliner gerektirir... Aksi takdirde, bu benim için şaşırtıcıydı, işlev başlığı modülü derlemek için oldukça yeterli gibi görünüyor, ama hayır ... Bir gövdeye ihtiyacınız var ...
İyi iyi.
Ahhh... Şimdi neden program yazarken en sık yaptığım hatalardan birinin "Fonksiyonun bir gövdesi olmalı" olduğunu anlıyorum.
Bu inliner gerektirir... Aksi takdirde, bu benim için şaşırtıcıydı, işlev başlığı modülü derlemek için oldukça yeterli gibi görünüyor, ama hayır ... Bir gövdeye ihtiyacınız var ...
Hepsi doğru yazıyor, ancak optimize ediciyle hiçbir ilgisi yok.
Bir sınıf fonksiyonunun prototipi tanımlanmışsa, gövde de olmalıdır. Boş olsa bile.
Renat , MT4'te, grafikteki konumların görünürlüğünü terminalin genel parametrelerinde değil, her bir çizelge için ayrı ayrı kontrol etmenizi öneririm (MT5'te yapıldığı gibi).
SD'ye bu konudaki başvurum ikinci aydır hareketsiz duruyor.
Renat , MT4'te, grafikteki konumların görünürlüğünü terminalin genel parametrelerinde değil, her bir çizelge için ayrı ayrı kontrol etmenizi öneririm (MT5'te yapıldığı gibi).
SD'ye bu konudaki başvurum ikinci aydır hareketsiz duruyor.