Bug del compilatore con il parametro template = void* - pagina 5

Nuovo commento
 
Igor Makanu:

solo attraverso le stringhe, usavo StringConcatenate() per ottenere l'indirizzo del puntatore, come questo:

Non sapevo di StringConcatenate, è un peccato che in MT5 sia stato ridisegnato e non possa essere usato senza stringa s. E StringFormat è molto più veloce su 4.

E in generale questa operazione di "polling" del puntatore attraverso la stringa è due volte più lenta in cinque, anche se generalmente tutto è più veloce lì, a volte di un ordine
 
fxsaber:

Le parentesi rendono l'espressione completamente inequivocabile.

Perché questa ambiguità aggiuntiva, se un programmatore intelligente può fare tutto senza ambiguità? E se continuiamo nello spirito del "compilatore premuroso", allora tutte le espressioni in if dovrebbero essere racchiuse tra parentesi graffe, nel caso uno stupido programmatore confonda qualcosa.

Se parliamo di maggiore chiarezza, è sufficiente mettere degli spazi:

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

L'utilità di una tale matrice è discutibile, francamente. Cosa ci si può fare? Sapete che non chiamerete automaticamente la cancellazione dei membri dell'array, vero?

I distruttori di oggetti sono sempre virtuali
 
Alexey Navoykov:
I distruttori di oggetti sono sempre virtuali.

Provate. In caso di vuoto* non c'è alcuna possibilità.

 

la cancellazione non viene chiamata automaticamente per nessuno).

Un'altra cosa è che non impedisce al distruttore dell'array di passare attraverso la lista e cancellare tutti gli oggetti, se necessario

anche se è più vantaggioso usare un tipo base comune e memorizzare un riferimento ad esso per molte ragioni
 

Se volete eliminare CArayObject, dovete fare un override (come questo https://www.mql5.com/ru/forum/170952/page110#comment_9894796) sulla classe base e metterli in un array (possibilmente vostro), ma poi non avrete più bisogno di void*.

Non sono contro il vuoto*, è necessario, ma in una veste diversa.

 
pavlick_:

Provate. In caso di vuoto* non c'è alcuna possibilità.

Tutto funziona bene, perché ti stai inventando tutto?

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;
  }

Lo prendiamo nel registro:

void A::~A()
void B::~B()

Perché ci sono cascato comunque...

 
Alexey Navoykov:

Perché questa ambiguità aggiuntiva, se un programmatore intelligente può fare tutto senza ambiguità? E se continuiamo nello spirito del "compilatore premuroso", allora tutte le espressioni in if dovrebbero essere racchiuse tra parentesi graffe, nel caso uno stupido programmatore confonda qualcosa.

Se si tratta di maggiore chiarezza, è sufficiente mettere degli spazi:

Se vuoi più chiarezza con gli spazi, dovresti semplicemente mettere degli spazi nel codice.

 
A proposito delle staffe extra
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:

La visibilità sugli spazi è nulla - benvenuti nel mondo degli strumenti di styling.

Se uno styler rende illeggibile un codice difficile da leggere, allora non preoccupatevi dello styler.

Per me, uno styler è buono solo quando TUTTE le sue regole possono essere personalizzate in modo flessibile.

123456789101112...20
Nuovo commento