OOP, mql5'te şablonlar ve makrolar, incelikler ve kullanım teknikleri - sayfa 14
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
1. Yine de, bu "bir şeyin" olduğu yerde hemen bir şey hakkında konuşmak ve moderatörün bunu nasıl yapacağını düşünmemek daha iyidir. Ve sonra her şey gerçekten iki dalda bulanıklaştı ve şimdi, moderatör tartışmanın orada veya orada olması gerektiğine karar verse bile, gönderilerin sırasını ve anlamlarını koruyarak tartışmayı aktarmak normaldir, çok zaman alıcıdır. görev.
2. Moderatörün eylemlerinin tartışılması her hapşırma değildir ... Bu, eylemlerinin genel ve kamuya açık bir yarışması başlarsa, ayrıca düzeni yeniden sağlamak veya öfkeli olanları sakinleştirmek için eylemler başlar. Ve eğer kendi fikriniz varsa, o zaman bunu ifade etmenizi kim yasaklıyor? Belki fikriniz çok mantıklı bir öneri ama moderatörün sevilmeyen menüsü altına girmemek için söylemekten çekiniyorsunuz? Yani bu saçmalık :)
Açıklama için teşekkürler. Sözde değerli bilgileri ana konuya sızdırmamak için tartışmayı ayrı bir başlıkta tutmanın en iyisi olduğunu düşündüm. Gönderileri taşımaya karar verirseniz, nereye taşınacağınızı tartışırım.
Görünüşe göre henüz hangi dalda daha uygun olduğuna karar verecek bir moderatör değilsin. Ve moderatörler, özelliklerin tartışılmasının özelliklerin kendi başlığında değil, ayrı bir başlıkta, yani. burada.
Açıklamanızda, bir sınıf yöntemine referansa ve T tipinin değerine göre tek tip bir şekilde nasıl erişileceği hiç açık değil. Neden bahsettiğinizi bilmiyorum, ama ben orada bundan bahsediyordum.
Durum şu: Her şeyin forum üyelerinin o başlıkta görmeyi beklediği özelliklere göre düzenlenemeyeceğini anladım. Burada (ve orada devam ediyordu, bu yüzden buraya taşıdım) ayrı bir konuya ayırmaya karar verdiğim oldukça spesifik bir konu hakkında bir tartışma var. Çoğu için daha genel ve anlaşılır özellikler olsun ve burada - sınıflar, makrolar da dahil olmak üzere onlarla çalışmak için zor hileler (ki bu hala birçokları için bir bilmecedir).
Açıklama için teşekkürler. Sözde değerli bilgileri ana konuya sızdırmamak için tartışmayı ayrı bir başlıkta tutmanın en iyisi olduğunu düşündüm. Gönderileri taşımaya karar verirseniz, nereye taşınacağınızı tartışırım.
Bırak şimdi öyle kalsın. Sadece - mümkünse - tartışılan örneği oradan gönderinize kopyalayın, bu örneğe atıfta bulunur (burada nasıl başladığını anlamak benim için zor). Peki, ya da artık gönderinizi düzenleyemiyorsanız, kişisel bir mesajda neyi nereye ekleyeceğimi söyleyin.
Bırak şimdi öyle kalsın. Sadece - mümkünse - tartışılan örneği oradan gönderinize kopyalayın, bu örneğe atıfta bulunur (burada nasıl başladığını anlamak benim için zor). Peki, ya da artık gönderinizi düzenleyemiyorsanız, kişisel bir mesajda neyi nereye ekleyeceğimi söyleyin.
Kodu birkaç mesaj önce bu konudan buraya kopyaladım, bu yüzden IMHO ek adım gerekli değil.
Kodu birkaç mesaj önce bu konudan buraya kopyaladım, bu yüzden IMHO ek adım gerekli değil.
İyi.
Şablonlar ve istatistikler aracılığıyla arayüzler konusunda güncelleme. Daha doğrusu, arayüzler değil, diyelim ki, harici sınıflar aracılığıyla uygulanan keyfi türler üzerinde uygun şekilde parametreli işlemler. Bu durumda karşılaştırma (Karşılaştırıcı) ve tip döküm (Caster)
Önceki eleştiriyi kısmen dikkate aldım, "arayüz" sınıfı (arayüz olmasa da) parametre sınıfından miras alınmadı (böyle bir yöntem kök salmadı ...) ve elbette dynamic_cast kullanmadan. Umarım bu model daha mantıklı görünür.
böyle bir kod parçası için bir makro oluşturmak ne kadar gerçekçi:
Girdi değişkenlerinin ( input ) sayısına henüz karar vermedim, seçili alanı düzenlemekten yoruldum , tek satırlık makro sorun değil ama 10-15 ile çarpmayı bilmiyorum çizgiler
böyle bir kod parçası için bir makro oluşturmak ne kadar gerçekçi:
Girdi değişkenlerinin ( input ) sayısına henüz karar vermedim, seçili alanı düzenlemekten yoruldum , tek satırlık makro sorun değil ama 10-15 ile çarpmayı bilmiyorum çizgiler
Hemen söylüyorum - µl için kontrol etmedim, sadece kontrol etmek için C-serisi önişlemciden geçirdim, çünkü MKL'nin özellikleri var, varsa tamamlayın.
egzozu aldım (gcc -E):
bağımsız değişkenler listesine eklediğiniz/attığınız ek argümanlar.
böyle bir kod parçası için bir makro oluşturmak ne kadar gerçekçi:
Girdi değişkenlerinin ( input ) sayısına henüz karar vermedim, seçili alanı düzenlemekten yoruldum , tek satırlık makro sorun değil ama 10-15 ile çarpmayı bilmiyorum çizgiler
Şimdiye kadar sadece anladım. Şimdi, geliştiriciler C'de olduğu gibi değişken sayıda parametreyi vidalasaydı, o zaman kısaltmak mümkün olabilirdi.
Şimdiye kadar sadece anladım. Şimdi, geliştiriciler C'de olduğu gibi değişken sayıda parametreyi vidalasaydı, o zaman kısaltmak mümkün olabilirdi.
Fazla karmaşıklaştırdığım bir şey)).
Eh, muhtemelen ilk, en uygun olanı kullanmasına izin verin.
#define TEST(dId)
Sonuçta birkaç kez TEST yazmak sorun değil.