Parıltı ve sefalet OOP

Yeni yorum
 

Başlangıç sırasında ayarlanan parametrelere bağlı olarak temel sınıf, birkaç soyundan, soyundan biri kullanılır. Bu, evrensel programın iyi bilinen bir ilkesidir. Ne kadar seçenek olursa olsun (yani alt sınıflar), programı değiştirmek için if veya anahtar çağrıları olmadığından, başlatma sırasında yalnızca bir kez istenen alt sınıf seçildiğinden, bu işin çok hızlı çalışması gerektiği anlaşılmaktadır, o zaman her şey doğrudan ve basit bir şekilde çalışır.

 class CBase{
   private :
   public :
       virtual void Fun(){
      
      }
};

class CClass1:CBase{
   private :
   public :
       void Fun(){
      
      }
};

CClass1 * cl;

void OnInit (){

   cl= new CClass1;

}

Yine de...

Kaç farklı seçenek olabilir? makul sayı? 10, 20, 100? 100 seçenekle bile, geçiş OOP'den daha hızlıdır.

Uygulamada, performansı karşılaştırmak için bir komut dosyası. Yukarıdaki OOP karşılaştırılır ve sadece işlevlerle değiştirilir (ayrıca iki işlev çağrılır,işlev çağrılarından biri kolayca ortadan kaldırılabilir).

 void ff( int z){

       switch (z){
         case 0 :
         f0();
         break ;

         ...

         case 99 :
         f99();
         break ;

      }
     
}
Sonuçlar (f99'u arayın):

Dosyalar:
test.mq4  9 kb
 
Integer :

Kaç farklı seçenek olabilir? makul sayı? 10, 20, 100? 100 seçenekle bile, geçiş OOP'den daha hızlıdır.

Aşırı genellemeye karşı uyarmak istiyorum. Sanal "sözde işaretçiler" kullandığı için mql'de böyle bir etki beklemek mantıklıdır - aslında, gerçek adreslerin dahili (gizli) karma tablosuna atıfta bulunan işler. Bu tür işaretçileri çözmek için, işaretçiye doğrudan hitap etmekten çok daha fazla, önemli bir ek süre gereklidir. Bunu ölçmedim, ancak dotNET dillerinde ve diğer benzer uygulamalarda benzer bir işaretçi "yavaşlama" etkisinin bulunması muhtemeldir.

"Gerçek" işaretçilere sahip dillerde, böyle bir etki olmayacak, anahtar orada kaybolacak - ne kadar çok seçenek listesi o kadar büyük.

Yani OOP'nin bununla hiçbir ilgisi yok.

 
MetaDriver :

Aşırı genellemeye karşı uyarmak istiyorum. Sanal "sözde işaretçiler" kullandığı için mql'de böyle bir etki beklemek mantıklıdır - aslında, gerçek adreslerin dahili (gizli) karma tablosuna atıfta bulunan işler. Bu tür işaretçileri çözmek için, işaretçiye doğrudan hitap etmekten çok daha fazla, önemli bir ek süre gereklidir. Bunu ölçmedim, ancak dotNET dillerinde ve diğer benzer uygulamalarda benzer bir işaretçi "yavaşlama" etkisinin bulunması muhtemeldir.

"Gerçek" işaretçilere sahip dillerde, böyle bir etki olmayacak, anahtar orada kaybolacak - ne kadar çok seçenek listesi o kadar büyük.

Yani OOP'nin bununla hiçbir ilgisi yok.

Sorunun yalnızca derleyicinin kendisinde olduğu açıktır, bu nedenle "doğru" derleme ile yukarıdaki örneklerin yürütme süresi eşit olacaktır.
 
icas :
Sorunun yalnızca derleyicinin kendisinde olduğu açıktır, bu nedenle "doğru" derleme ile yukarıdaki örneklerin yürütme süresi eşit olacaktır.
"Doğruluk" kavramı kurallara bağlıdır, bu nedenle anlamsızdır. ;)
 

Hatayı hemen belirteceğim: f kukla bir işlevdir ve derleyici tarafından tamamen kesilmiştir. Yani, aslında, hiçbirişlev çağrısı yoktur. Ayrıca, ff işlevinin hangi durumda dejenere olacağından ve sonunda for döngüsü içinde satır içi olup olmayacağından, böylece işlev çağrısını bile kaldıracağından emin değilim.

Ancak sanal yöntem kesilemez - her zaman çağrılır. Sonuç olarak, bir durumda döngü basitçe dönüyor ve diğerinde çağrı döngüde.

Herhangi bir testte, her şeyden önce, doğruluğunu kanıtlamak ve ancak daha sonra sonuçlara geçmek gerekir.

 

Burada boş olmayan işlevlerle:

Dosyalar:
test2.mq4  11 kb
 

İşte tüm benzersiz işlevler, ayrıca geçiş yoluyla çağrılanlar , sınıf yönteminden daha karmaşıktır.

Dosyalar:
test3.mq4  12 kb
 
Integer :

İşte tüm benzersiz işlevler, ayrıca geçiş yoluyla çağrılanlar , sınıf yönteminden daha karmaşıktır.

Her şey nasıl başladı...

Inlining'i duydunuz mu? Agresif satır içilemeye ne dersiniz?

Basit işlev gövdelerine genellikle ne olur ve normal bir optimize edici derleyici bunlarla ne yapar? Şimdi 1995 değil.

 
MetaDriver :

Aşırı genellemeye karşı uyarmak istiyorum. Sanal "sözde işaretçiler" kullandığı için mql'de böyle bir etki beklemek mantıklıdır - aslında, gerçek adreslerin dahili (gizli) karma tablosuna atıfta bulunan işler. Bu tür işaretçileri çözmek için, işaretçiye doğrudan hitap etmekten çok daha fazla, önemli bir ek süre gereklidir. Bunu ölçmedim, ancak dotNET dillerinde ve diğer benzer uygulamalarda benzer bir işaretçi "yavaşlama" etkisinin bulunması muhtemeldir.

"Gerçek" işaretçilere sahip dillerde, böyle bir etki olmayacak, anahtar orada kaybolacak - ne kadar çok seçenek listesi o kadar büyük.

Yani OOP'nin bununla hiçbir ilgisi yok.

Evet. İşte C keskinliğinde :)


 7550021 (anahtar)
2250004 (OOP)
7325029 (anahtar)
2050015 (OOP)
7550049 (anahtar)
2150005 (OOP)
7575031 (anahtar)
2325009 (OOP)
8025038 (anahtar)
2200004 (OOP)
7150027 (anahtar)
2050014 (OOP)
7375029 (anahtar)
2200005 (OOP)
7550022 (anahtar)
1950003
7100021 (anahtar)
2695083
7360033 (anahtar)
2200008 (OOP)
7825029 (anahtar)
1925010 (OOP)
7325025 (anahtar)
20205006 (OOP)
6850035 (anahtar)
2525014 (OOP)
7750027 (anahtar)
197507 (OOP)
8195225 (anahtar)
2050004 (OOP)
6950020 (anahtar)
2425006 (OOP)
7275029 (anahtar)
2225015 (OOP)
7050037 (anahtar)
2200007 (OOP)
7375030 (anahtar)

 

Herhangi bir teste, doğru olduğuna ve belirtilenlerin gerçekten içinde ölçüldüğüne dair kanıtlarla başlayın.

Yukarıda sunulanlar şaşırtıcı hatalar içeriyor ve derleme mekanizmalarının yazarının ve kodun nasıl çalıştığını tam olarak anlamadığını gösteriyor.

 
Renat :

Herhangi bir teste, doğru olduğuna ve belirtilenlerin gerçekten içinde ölçüldüğüne dair kanıtlarla başlayın.

Yukarıda sunulanlar şaşırtıcı hatalar içeriyor ve derleme mekanizmalarının yazarının ve kodun nasıl çalıştığını tam olarak anlamadığını gösteriyor.

Derleme mekanizmalarını neden anlamalıyım? Sadece kötü bir sonucun iyi bir sonuçtan daha iyi olduğuna inanmak için mi? Sonuç önemli.
1234567
Yeni yorum