MQL5 Il compilatore non distingue tra una classe e un puntatore ad essa - pagina 6
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
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:
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".
Trovare un luogo di errore nel codice dove tutto è così "implicito" sarà una bella sfida.
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).
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
in modo che non permetta di compilare la merda che ora è considerata buona.
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.come A a = nuovo A? O che cosa esattamente )
Beh, non c'è bisogno di dirlo. C'è una perdita di memoria qui.
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.
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.
Se avete un oggetto a sinistra, perché scrivere una tale costruzione?
Il fattore umano! Il compilatore dovrebbe tenerlo al minimo.
Il fattore umano! Il compilatore dovrebbe tenerlo al minimo.