MQL5'te OOP gerekli olacak mı? - sayfa 6

 

Güçlü bir istekle, OOP, hala bir tercüman olan BASIC'te de bulunabilir. Evet.


OOP'nin göstergelerde, Uzman Danışmanlarda ve senaryolarda nasıl talep göreceğini bekleyip görmemiz gerektiğini düşünüyorum. Ve aslında zaten nasıl olduğuna karar verin.

 

HideYourRichess писал(а) >>

OOP'nin göstergelerde, Uzman Danışmanlarda ve senaryolarda nasıl talep göreceğini bekleyip görmemiz gerektiğini düşünüyorum. Ve aslında zaten nasıl olduğuna karar verin.

Şimdi, bu arabelleklerin göstergelerdeki tüm ilgili olanlarla kopyalanmasını otomatikleştirmeye çalışıyorum. Zor, zor çıkıyor, referans eksikliği, parametreli yapıcılar (RAII gerçekleştirilemez), vb.

Ve teslimatta gelen benzer şey bana uymuyor. Hiç.

C-4 yazdı >>

ZY Çoğu kişi OOP'yi belirli bir C++ programlama diliyle ilişkilendirir.

Ve ne, gerçekten kötü uygulanıyor mu? IMHO, oldukça kendine bile. Diğer normal nesne yönelimli dillerde olduğu gibi.

, MQ5 OOP'dir,

Sadece burada fırsatlar açısından fakir

OOP, C'de bile var, ancak bir nedenden dolayı çoğu kişi bunu bilmiyor, bu da yine yüzeysel bilgiden bahsediyor.

Ama bundan böyle daha detaylı.

 
TheXpert >> :

Şimdi, bu arabelleklerin göstergelerdeki tüm ilgili olanlarla kopyalanmasını otomatikleştirmeye çalışıyorum. Zor, zor çıkıyor, referans eksikliği, parametreli yapıcılar (RAII gerçekleştirilemez), vb.

Ve teslimatta gelen benzer şey bana uymuyor. Hiç.

Dürüst olmak gerekirse, ben de aynısını denedim. Özel bir şey yok, çok şımartıcı. Fırlattı, bir baskınla nifiga değerli bir şey yapmadı. Ya çok şeyi yeniden öğrenmem gerekiyor ya da OOP'nin genişletilmesi gerekiyor. Ne biri ne de diğeri henüz gelmedi. Genel olarak, komisyondan geçtim, bu kadar aptal mıyım yoksa teknik desteğe bilet göndermem gerekip gerekmediğini anlamadım, - şimdilik hepsini puanladım.

 

Lütfen, detaylandırabilir miyim:

KAPSÜLLEME:

struct mail

{

      int zipcode;

      char adr[50];

      char comment[10];

     ...

}

Kendi içinde yapıların varlığı korumasız bir kapsüllemedir.

STATİK POLİMORFİZM:

double d=3.12, c;

int i=5;

c= d+i ;

(Farklı veri türleri aynı operatör tarafından toplanır)

DİNAMİK POLİMORFİZM:

void qsort(void *buf, size_t st, size_t s, int (*compare) (const void *, const void *));

qsort işlevi, karşılaştırma alt işlevinin türüne bağlı olarak farklı davranır.

MİRAS:

Dinamik polimorfizmdekiyle aynı örnek, bu durumda, qsort işlevi, olduğu gibi, karşılaştırma() işlevinin özelliklerini alır.

 
C-4 >> :

Lütfen, detaylandırabilir miyim:

Böyle bir şey ve görülmesi bekleniyor. Yalnızca statik polimorfizm sayılır. Bu konuyla ilgili tartışmaya devam etmenin bir anlamı görmüyorum (C'de OOP) ve yapmayacağım.

Gerçekten şaşıracağını düşündüm.

 
Klasik işlev aşırı yüklemesi gibi bir şey görmek istiyorsanız, vb. LCC gibi bazı modern C derleyicilerini indirin ve daha yakından inceleyin. Örneğin LCC, sınırlı da olsa klasik OOP'yi destekler, ancak bu standardın kapsamı dışındadır.
 

bazılarını özetlemek çok ön sonuçlar olarak, üst alıntıların uygulanmasında OOP'nin deneyimli programcılar tarafından bile kabul edilmediğini söyleyebiliriz. Muhtemelen uygulama nedeniyle. Belki de buna alışmanız gerekiyor ve OOP ile gerçekten daha uygun olacak. Ama şimdilik, olan var. Olmadan daha iyi görünüyor. Onlar. Muhtemelen bir şeyler yazmak mümkündür, ancak yalnızca OOP uğruna ve pratiklik için değil, yazma hızı için, her durumda PP'ye karşı daha yavaş olacak olan kodun hızından bahsetmiyorum.

O zaman o gider...

 

Ama OOP talebi gerçekten bu kadar önemli mi (bu kısaltmanın ne anlama geldiğini kim anlarsa)? benim için, bir tüccarın ve bir programcının işini kolaylaştıracak yeni ticaret ve hizmet fonksiyonlarının ne kadar ortaya çıkacağı ve bunların ne kadar iyi/tam olarak uygulanacağı çok daha önemli.

Peki, göstergelerle nesne oluşturmanın imkansızlığı ile (muhtemelen zaten ağrılı olan) örneğe bir göz atalım. Bana en az bir düzine MQL5 OOP standartlarına uygunluk sertifikası gösterebilirsiniz, ancak göstergeler tarafından nesneler oluşturulmadan hiçbir OOP sizi ekranda en basit metni görüntüleme karmaşıklığından kurtaramaz. Veya başka bir örnek: bir grafikteki bir grafik nesnesi, bu grafik nesnesine banal bir onay işareti bile ekleyemiyorsanız, OOP kullanmanın gururunun ne anlamı var? ve bir onay kutusu olarak çalışan düğme ve standart bir birleşik giriş kutusunun olmaması, böylece, örneğin, bir Uzman Danışmanda, hesaplamalar için bir zaman çerçevesi ve birkaç nesneyi tek bir nesnede gruplandırma yeteneği seçebilirsiniz. diyalog formu düzenleyicisi hakkında sessiz, çünkü platformun otomatik ticaret için nasıl ayarlandığı... :(

IMHO: MQL5'te, klasik OOP'nin doğasında bulunan yalnızca (kuvvetle) kesilmiş bir özellik alt kümesi vardır. Geliştiriciler çok büyük miktarda iş yaptılar ve elbette kaynak kodunu yazmayı büyük ölçüde yüceltiyor ve basitleştiriyor, ancak bunların hepsi "dama", ancak yine de bir taksi istiyorum ve geliştiricilerin yakında MQL6'yı başlatmayacağını umuyorum, ancak tam olarak beş "şartları getirmeye" devam edecek;)

 
ForexTools >> :

Ama OOP talebi gerçekten bu kadar önemli mi (bu kısaltmanın ne anlama geldiğini kim anlarsa)? benim için, bir tüccarın ve bir programcının işini kolaylaştıracak yeni ticaret ve hizmet fonksiyonlarının ne kadar ortaya çıkacağı ve bunların ne kadar iyi/tam olarak uygulanacağı çok daha önemli.

Tabiiki. Ve bu konuda ilgili branşlarda çok şey söylendi. Örneğin, bana öyle geliyor ki MK, eski sorunlarla uğraşmak yerine, çözümlerini yalnızca yeniliklerle karmaşıklaştırdı.

Şimdi OOP'tan bahsetmiyorum. Ancak bu fırsat için harcanan enerji, gerçekten yararlı ve talep gören bir şeye yönlendirilebilir.

 
Svinozavr >> :

Tabiiki. Ve bu konuda ilgili branşlarda çok şey söylendi. Örneğin, bana öyle geliyor ki MK, eski sorunlarla uğraşmak yerine, çözümlerini yalnızca yeniliklerle karmaşıklaştırdı.

Şimdi OOP'tan bahsetmiyorum. Ancak bu fırsat için harcanan enerji, gerçekten yararlı ve talep gören bir şeye yönlendirilebilir.

Soru, genel olarak, kolay bir soru değil. Aslında. Sunucuda değişiklik görmüyoruz. İnternetten alınan parça parça bilgilere göre, orası olduğundan daha havalı görünüyor. Bu, elbette, DC için bizim için değil, ancak diğer yandan hizmet genel olarak iyileşebilir.