Errori, bug, domande - pagina 2358

[Alexey Navoykov]

Ilya Malev:

Sebbene anche se l'oggetto non avesse metodi virtuali, dovreste comunque controllare la validità del puntatore quando vi accedete.

In realtà questa è una domanda ambigua. Per esempio, questo controllo è sempre presente in C# e solo se necessario in C++, il che dà un vantaggio in velocità.

Dopo tutto, se si chiama un metodo che non accede ai campi di un oggetto, non ha davvero senso controllare il puntatore. In sostanza, un tale metodo è equivalente a uno statico.

[Ilya Malev]

Alexey Navoykov:

In generale, questa è una questione ambigua. Per esempio, C# ha sempre un tale controllo, mentre C++ lo ha solo quando serve, il che dà un vantaggio in termini di velocità.

Perché se state chiamando un metodo senza riferimenti ai campi dell'oggetto, non ha davvero senso controllare il puntatore. Un tale metodo è essenzialmente lo stesso di uno statico.

Un oggetto può non avere alcun dato, ma può implementare un comportamento assolutamente diverso e criticamente importante, ad esempio riferirsi a qualche dato esterno in un modo speciale dipendente dal tipo, o eseguire un'azione speciale. Non sono sicuro di come giustificare tale approccio come "equivalenza del metodo al metodo statico (cioè 100% non virtuale) in assenza di dati".

Cioè, almeno un oggetto puntatore ha sempre un campo - è il suo tipo. Con cui potete determinare gli indirizzi dei metodi che vengono chiamati. Altrimenti perché avete bisogno di OOP?

P.S. Anche se per gli oggetti automatici personalmente non ho nulla contro almeno una certa logica di comportamento (dato che quasi non li uso), ma poi non si dovrebbe lasciare che siano assegnati ai puntatori

[Ilyas]

Purtroppo ho ingannato tutti, perché le costruzioni

B *b=a;
B b=a;

l'operatore di copia viene chiamato al posto del costruttore di copia.
Nel secondo caso, dopo che il costruttore B() è chiamato

In ogni caso, prima analizziamo, poi correggiamo.

[pavlick_]

Oh, si scopre che µl ha un costruttore di copia autogenerato (pensavo non esistesse affatto, dato che non si può classificare obj(other_obj), solo con =). Ma perché non viene generato se:

class Q
{
public:
   Q(Q&)=default;  // нельзя
   Q(int) {}       // из-за него копирующий конструктор исчез
};

[Ilyas]

pavlick_:

Oh, si scopre che µl ha un costruttore di copia autogenerato (pensavo non esistesse affatto, dato che non si può classificare obj(other_obj), solo con =). Ma perché non viene generato se:

default e delete non sono supportati.

Il costruttore di copie di default, a quanto pare, è stato fatto finora.

Solo operatore di copia, cioè per i costrutti:

CFoo foo=another_foo;

Il costruttore CFoo predefinito viene chiamato per primo, e poi l'operatore di copia

[Alexey Navoykov]

Ilyas:

viene chiamato l'operatore di copia, non il costruttore di copia.

Ma questo è ancora un errore, perché l'operatore di copia implicita dovrebbe essere creato solo per la classe B, non per tutte le classi madri. cioè l'oggetto non dovrebbe essere autorizzato a sostituire parzialmente i suoi interni.

[pavlick_]

Ilyas:

default e delete non sono supportati

È vero, ma avete solo bisogno di sovrascrivere la generazione del costruttore di copia quando c'è un costruttore di copia personalizzato, no? Non uno qualsiasi personalizzato.

[A100]

Alexey Navoykov:
Cioè l'oggetto non dovrebbe essere permesso di sostituire parzialmente le sue parti interne.

Questa è una specie di autolimitazione artificiale... Direi addirittura la ristrettezza di vedute.

class A {};
class B : public A {
public:
        void operator =( const A& ) {}
};

Qual è il problema?

Ho trovato un tale disegno in me stesso... e funziona... bene. Quindi suggerisco agli sviluppatori di lasciarlo così com'è... almeno se gli operatori/costruttori corrispondenti sono esplicitamente definiti

[Alexey Navoykov]

A100:

Questa è una specie di autolimitazione artificiale... Direi addirittura la ristrettezza di vedute.

Qual è il problema?

Ho trovato un tale costrutto a casa mia... e tutto funziona... bene. Quindi suggerisco agli sviluppatori di lasciarlo così com'è... almeno se i relativi operatori sono esplicitamente definiti

Controlla per cominciare come funzionano le cose in C++. Apparentemente le sue regole sono state inventate da persone di "mentalità ristretta".

E creare dei tappi per proteggersi da un'architettura linguistica sbagliata ogni volta... No, bisogna farlo fin dall'inizio, cioè la lingua

[A100]

Alexey Navoykov:

Controlla prima come funzionano le cose in C++. Apparentemente le sue regole sono state inventate da persone di "mentalità ristretta".

Ma fare dei tappi ogni volta per proteggersi da un'architettura linguistica sbagliata... No, bisogna farlo fin dall'inizio, intendo la lingua.

Ricontrollato appositamente per voi, tenendo conto di https://www.mql5.com/ru/forum/1111/page2358#comment_10003995

#ifdef __cplusplus
#include "https://www.mql5.com/ru/forum/1111/page2358#comment_10003995"
void OnStart()
{
        A a;
        B b;
        b = a;
}
#endif

Va bene DJ