Mql5 dilinin özellikleri, incelikleri ve çalışma yöntemleri - sayfa 213

Yeni yorum
 
A100 # :

Ve mevcut işlevlerin davranışını değiştirmenize gerek yok - sadece yeni doğru işlevler ekleyin (bazı önek / sonek ile) ve ilgili bir uyarının verilmesiyle öncekilerin geçersiz olduğunu ilan edin.

FileReadArray'in tüm amacı yok edilsin mi? Bu işlevleri bir hafıza parçasının yedeği olarak düşünün. Sadece bayt.

 
fxsaber # :

FileReadArray'in tüm amacı yok edilsin mi? Bu işlevleri bir hafıza parçasının yedeği olarak düşünün. Sadece bayt.

Onlar. Önce private, const yoluyla kendin için zorluklar yaratmayı, sonra da "doğrudan" hafıza erişimiyle onları kahramanca aşmayı mı öneriyorsun?

Farklı bir yaklaşımım var - böyle bir ihtiyaç ortaya çıkarsa, program başlangıçta yanlış tasarlandı

 
A100 # :

Onlar. Önce private, const aracılığıyla kendin için zorluklar yaratmayı öneriyorsun.

Private/const'tan her zaman büyük fayda sağlarım. Programın mimarisi üzerinde çok iyi kontrol sağlarlar.

ve ardından "doğrudan" bellek erişimiyle kahramanca üstesinden gelmek mi?

Üstesinden gelmek yok. Her şey çok basit ve mantıklı.

Farklı bir yaklaşımım var - böyle bir ihtiyaç ortaya çıkarsa, program başlangıçta yanlış tasarlandı

OOP "saflığı" uğruna mimari kontrolün rahatlığını kaybederek (özel / const olmadan) her şeyi bir yığın halinde yazmaya hazır olduklarını anlıyorum.

 
Ilyas # :

Dosya... işlevleri gizlilik ve sabitlik olmadığında ortaya çıktı, şimdiye kadar bu davranışı değiştirmeyi düşünmediler, çünkü kritik olarak görmüyoruz.

CharArray<->Struct son zamanlarda ortaya çıktı, ancak private/const ile mükemmel bir şekilde sürün. Umarım tekrar ziyaret edilmezler.

 
Kodun saflığı için, yapılar için serileştirme ve serileştirme yöntemlerini yazmanız gerekir. O zaman gizlilikle herhangi bir çakışma olmaz ve seri durumdan çıkarma sırasında değiştirilebiliyorlarsa sabit alanlar sabit değildir.
 
fxsaber # :

OOP "saflık" uğruna mimari kontrolün rahatlığını kaybederek (özel / const olmadan) her şeyi bir yığın halinde yazmaya hazır olduklarını anlıyorum.

Yanlış anlıyorsunuz - OOP açısından, nesne kendi kendine yeterli (harici işlevler gerektirmez) - buna göre, özel ile herhangi bir çatışma yok. Ve const ile bir çakışma varsa, doğru şekilde belirtildiği gibi:

onları yapay olarak yaptın
 
fxsaber # :

OOP "saflığı" uğruna mimari kontrolün rahatlığını kaybederek (özel / const olmadan) her şeyi bir yığın halinde yazmaya hazır olduklarını anlıyorum.

daha doğrusu tam tersi. Daha az kullanışlı ancak daha güvenli kurallı yaklaşımı kullanmak yerine, herhangi bir DMA boşluktan yararlanmaya hazırsınız.

 
TheXpert # :

daha doğrusu tam tersi. Daha az kullanışlı ancak daha güvenli kurallı yaklaşımı kullanmak yerine, herhangi bir DMA boşluktan yararlanmaya hazırsınız.

İki istek:

  1. Yapıyı kaydetme ve yükleme kodunu gösterin.
  2. Kanonik olmayan bir yaklaşımın tehlikesine bir örnek.
 

Bu yüzden çok büyük bir bug. Misal: 

class C{
   static uint count;
   const uint number;
public :
   C():number(++count){ PrintFormat ( "C[%i]" ,number);}
  ~C(){ PrintFormat ( "~C[%i]" ,number);}
   uint Number() const { return number;}
};
uint C::count= 0 ;

void OnStart ()
{
  C c[ 3 ]={};
   for ( int i= 0 ;i< ArraySize (c); Print (c[i++].Number()));
}
 2021.11 . 18 16 : 03 : 31.424 test (EURUSD,M1)         0
2021.11 . 18 16 : 03 : 31.424 test (EURUSD,M1)         0
2021.11 . 18 16 : 03 : 31.424 test (EURUSD,M1)         0
2021.11 . 18 16 : 03 : 31.424 test (EURUSD,M1)        ~C[ 0 ]
2021.11 . 18 16 : 03 : 31.424 test (EURUSD,M1)        ~C[ 0 ]
2021.11 . 18 16 : 03 : 31.424 test (EURUSD,M1)        ~C[ 0 ]

Bellek tahsis edilir, serbest bırakıldığında yıkıcı çağrılır (bu, RAII'ye göre beklenen davranış hakkında bir ipucudur), ancak bir nesne oluştururken yapıcıyı çağırmayı unuttular)))

 

Daha önce böyle bir yazı görmemiştim.

1...206207208209210211212213214215216217218219220...247
Yeni yorum