Şablon parametreli derleyici hatası = void* - sayfa 5

Yeni yorum
 
Igor Makanu :

yalnızca dizeler aracılığıyla, işaretçinin adresini StringConcatenate () aracılığıyla alırdım, bunun gibi bir şey:

StringConcatenate hakkında bir şey bilmiyordum, MT5'te yeniden yapılmış olması ve artık string s olmadan kullanılamaması üzücü. Ve dördüncüsünde, StringFormat gözle görülür şekilde daha hızlı çıkıyor

Ve genel olarak, herhangi bir nedenle, ilk beşte, bir işaretçiyi bir dize aracılığıyla "basitleştirme" işlemi neredeyse iki kat daha yavaştır, ancak temelde her şey orada daha hızlı, bazen bir büyüklük sırasına göre daha hızlı çalışır.
 
fxsaber :

Parantezler, ifadenin yorumlanmasında tam bir belirsizlik sağlar.

Akıllı bir programcı için her şey zaten açıksa, neden bu ek belirsizlik? Ve eğer "ilgili bir derleyici" ruhu içinde devam ederseniz, o zaman tüm ifadelerin kaşlı ayraçlar içine alınmasını istemeniz gerekir, aksi takdirde aptal bir programcı bir şeyleri karıştırır.

Daha fazla netlikten bahsediyorsak, bunun için boşluk bırakmak yeterlidir: 

a<< 1 | b<< 2 | c<< 3
 
pavlick_ :

Dürüst olmak gerekirse, böyle bir dizinin şüpheli yararı. Onunla ne yapabilirsin? Dizi üyeleri için silme işleminin otomatik olarak çağrılmayacağını biliyor musunuz?

Nasıl oluyor? Nesne yıkıcılar her zaman sanaldır
 
Alexey Navoykov :
Nasıl oluyor? Nesne yıkıcılar her zaman sanaldır

Ve sen dene. Void* durumunda, hiç şans yoktur.

 

delete hiç kimse için otomatik olarak çağrılmaz. bu yüzden silinir)

başka bir şey de, bu, dizinin kendisinin yıkıcısının listeyi gözden geçirmesine ve gerekirse tüm nesneleri kaldırmasına hiçbir şekilde müdahale etmemesidir.

ortak bir temel türü kullanmak ve ona bir referans tutmak birçok nedenden dolayı daha faydalı olsa da
 

Döküğe bir CArayObject göndermek istiyorsanız, temel sınıf üzerinde bir sarmalayıcı (bunun gibi https://www.mql5.com/en/forum/170952/page110#comment_9894796) yapmanız ve bunları bir dizi (belki sizinki), ancak o zaman void*'e ihtiyacınız yoktur.

Boşluğa karşı değilim*, gerekli ama farklı bir kapasitede.

 
pavlick_ :

Ve sen dene. Void* durumunda, hiç şans yoktur.

Evet, her şey yolunda gidiyor, ne icat ediyorsunuz:

 class B
{
 public : 
  ~B() { Print ( __FUNCSIG__ ); }
};

class A
{
 public : 
  B b;
  ~A() { Print ( __FUNCSIG__ ); }
};

void OnStart ()
  {
   A* a= new A;
   
   void * p= a;
   delete p;
  }

Günlükte şunları elde ederiz:

geçersiz A::~A()
geçersiz B::~B()

Ve neden buna kandım ki...

 
Alexey Navoykov :

Akıllı bir programcı için her şey zaten açıksa, neden bu ek belirsizlik? Ve eğer "ilgili bir derleyici" ruhu içinde devam ederseniz, o zaman tüm ifadelerin kaşlı ayraçlar içine alınmasını istemeniz gerekir, aksi takdirde aptal bir programcı bir şeyleri karıştırır.

Daha fazla netlikten bahsediyorsak, bunun için boşluk bırakmak yeterlidir:

Alanlarda görünürlük hiçbir şey ifade etmez - stilistlerin dünyasına hoş geldiniz.

 
ek hakkında parantez
 class A
{
public :
   int i;
  
  A* GetPtr()
  {
     this .i = 1 ;
    
     return (& this );
  }
  
   void f()
  {
     Print ( this .i);
  }
};

class B : public A
{
public :
   void * GetPtr()
  {
     this .i = 2 ;
    
     return (& this );
  }
};

void g( A* a)
{
  a.f();
}

void OnStart ()
{    
  B* b = new B;
  
//   b.GetPtr().f(); // 'f' - member function not defined
  
  ((A*)b).GetPtr().f();   // 1
  ((A*)b.GetPtr()).f();   // 2
  ((A*) ( b.GetPtr() ) ).f(); // Доп. скобки, чтобы подчеркнуть, что именно имелось в виду, не полагаясь на приоритеты.

   delete b;
}
 
fxsaber :

Alanlarda görünürlük hiçbir şey ifade etmez - stilistlerin dünyasına hoş geldiniz.

Stilist kodu okunabilir koddan okumayı zorlaştırıyorsa, belki böyle bir stilist onun için çalışmıyor?

Bana gelince, bir şekillendirici ancak TÜM kuralları esnek bir şekilde özelleştirilebildiğinde iyidir.

123456789101112...20
Yeni yorum