MQL5 Il compilatore non distingue tra una classe e un puntatore ad essa - pagina 6

 
Alexey Navoykov:

Fusione implicita di questo puntatore a un oggetto

Il nome corretto è "Implicit pointer dereferencing".

Appoggio la proposta di non permettere, lasciare la dereferenziazione implicita solo quando ci si riferisce a un membro della classe, come:

m_a.foo()
 
Alexey Navoykov:

Qui è il contrario - un puntatore è implicitamente castato in un oggetto (dereferenziato) e poi operator= viene applicato ad esso. fxsaber ne ha parlato anche ieri.

Anche se logicamente non contraddice le regole del MQL (poiché chiamare operator= è uguale a chiamare qualsiasi altro metodo dell'oggetto), porta ad ambiguità nella comprensione di tale codice e ad errori difficili da trovare. E questo non riguarda solo operator= ma anche == e !=. Forse questo casting dovrebbe essere proibito anche per altri operatori, perché in C++ si può applicare agli operatori: +-<>[].

La conclusione breve è questa: quando si applicano gli operatori che sono permessi per i puntatori in C++ a un puntatore, si proibisce un casting implicito di questo puntatore a un oggetto. Di conseguenza, l'esempio precedente avrebbe un errore di compilazione.

Sì, capisco. Con questi semplici esempi ho voluto mostrare a tutti i dubbiosi che il puntatore e l'oggetto sono entità diverse e non bisogna confonderli.

E questa circostanza richiede almeno un certo stile di scrittura del codice in modo da non commettere un errore e costruire codice che compilerà e persino passerà il test ma fallirà in condizioni reali, anche peggio se è stato scritto per la vendita. Non sarà un compito facile trovare un punto di errore nel codice dove tutto è così "implicito".

 
SemenTalonov:

Trovare un luogo di errore nel codice dove tutto è così "implicito" sarà una bella sfida.

Sì, sono un po' troppo impliciti, vero?
 

Sarebbe meglio che gli sviluppatori lasciassero le cose come stanno. Se ora iniziano a cambiare di nuovo la lingua, un mucchio di programmi smettono di compilare, o peggio, smettono di funzionare come previsto, ci sarà un putiferio in tutto il mondo.

Dal mio punto di vista, gli auto-oggetti in µl sono un rudimento, sottopuntatori con funzioni limitate (puntatore costante con auto-cancellazione), e per lo più non devono essere usati affatto (tranne che per il garbage collector).

 
Ilya Malev:

Sarebbe meglio che gli sviluppatori lasciassero le cose come stanno. Se iniziano a cambiare di nuovo ora, il linguaggio, un mucchio di programmi smettono di compilare, o peggio ancora, smettono di funzionare come previsto, ci sarà un putiferio mondiale.

I cambiamenti qui sono minimi. Si tratta solo di aggiungere regole di compilazione a

#property strict

in modo che non permetta di compilare la merda che ora è considerata buona.

 
SemenTalonov:

In modo che non ti permetta di compilare il tipo di eresia che ora è considerata buona.

come A a = nuovo A? O che cosa esattamente ) è ora usato da tutti, quindi non ha alcun effetto

Ma se si scrive A a, *b = a; si ottiene un errore di runtime, in questo caso il compilatore deve generare esplicitamente l'avviso "probabile uso di una variabile non inizializzata 'b'" come fa con tutti gli altri tipi. Se non è affatto un errore di compilazione. Ma non a causa dell'assegnazione di per sé, ma a causa dell'uso di una funzione sovraccaricata su una variabile non inizializzata che causa un errore di run-time, ovviamente. Questo è davvero un bug e sembra essere legato all'eccessiva ottimizzazione del codice.

E in generale non c'è eresia nell'assegnare auto a dino e viceversa, queste possono essere caratteristiche utili.

Ma cancellerei del tutto la copia implicita degli oggetti. Anche se è uno standard in C++. In realtà è la ragione di tutti questi problemi.
 
Ilya Malev:

come A a = nuovo A? O che cosa esattamente )

Beh, non c'è bisogno di dirlo. C'è una perdita di memoria qui.

Ilya Malev:

Ma in generale non c'è eresia nell'assegnare auto a dino e viceversa, queste possono essere caratteristiche utili.

Sì, lascia stare. Ma esplicito. E sarà fatto non per mio errore, ma perché devo farlo.

 
SemenTalonov:

Beh, questo è un dato di fatto. C'è una perdita di memoria qui.

Beh, questa perdita è puramente colpa tua: se hai un oggetto a sinistra, perché scrivi un costrutto del genere?

Ma la situazione inversa, quando si assegna qualcosa a un puntatore e questo viene improvvisamente dereferenziato, è un errore non ovvio.

Tutto è mescolato qui, sia le mosche che le cotolette. Sto parlando della discussione dell'argomento.

 
Alexey Navoykov:

Se avete un oggetto a sinistra, perché scrivere una tale costruzione?

Il fattore umano! Il compilatore dovrebbe tenerlo al minimo.

 
SemenTalonov:

Il fattore umano! Il compilatore dovrebbe tenerlo al minimo.

Quindi stai suggerendo di vietare del tutto la dereferenziazione implicita dei puntatori? Non credo che molte persone qui sarebbero felici di questo.