Errori, bug, domande - pagina 2363
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
typedef è un argomento, ho provato, ma non è andata bene, devo ancora capire dove ho sbagliato, il mio esempio dovrebbe funzionare anche con typedef!
Il codice che ho scritto sopra dovrebbe funzionare. Volevo controllare io stesso, ma senza fortuna: =)))))))))))
(costruire 1961)
typedef è un argomento, ho provato, ma non è andata bene, devo ancora capire dove ho sbagliato, il mio esempio dovrebbe funzionare anche con typedef!
Ma è possibile renderlo più semplice ed elegante - senza parentesi e puntatori inutili - (e si compila senza strani errori))))
Puoi renderlo più semplice ed elegante - senza parentesi e puntatori inutili - (e si compila senza strani errori))))
il tuo esempio non funziona nel mio caso, i miei oggetti sono creati dinamicamente, non gli assegno nemmeno un nome, mentre il tuo esempio usa un nome puntatore, ho provato in questo modo, il compilatore non lascia passare: '[' - name expected tst_cast.mq4 32 15
SZZ: ho iniziato a capire un po 'quello che suggerisci, ma ancora nessun risultato, posso fare a meno di dynamic_cast <>, aggiungere * campoCObject, in teoria dovrebbe essere così:
Penso che funzionerà un po' più velocemente del tuo esempio con dynamic_cast <> - il significato è lo stesso
se è possibile dereferenziare un puntatore *CObject in MQL?
Ho provato diverse varianti, ecco uno script di prova, aggiungo 3 elementi Myclass alla lista collegata e poi cambio i valori dei campi CMyclass, funziona:
Posso modificare i campi degli elementi CMyclass creati dinamicamente, senza puntatore intermedioCMyclass *result?
Inquesto modo:(CMyclass *)(base.GetCurrentNode()).x = 99;
PS: sospetto che tu abbia bisogno di usare typedef, ma finora senza successo
Quello che hai scritto è solo un uso implicito dello stesso:
Cioè un tale puntatore anonimo, ma fondamentalmente solo zucchero sintattico. Non c'è quasi zucchero in MQL, quindi non può essere fatto in questo modo. Ma dovrei notare che il casting al discendente è fatto senza controlli e conversioni, quindi non è chiaro perché non ti piace il lavoro esplicito con un puntatore.
ZS: un po 'iniziato a capire ciò che suggerisci, ma ancora nessun risultato, si può fare senza dynamic_cast <>, aggiungere un campo * CObject , in teoria, dovrebbe essere così:
Penso che funzionerà un po' più velocemente del tuo esempio con dynamic_cast <> - il significato è lo stesso
Si può fare senza un campo separato, come suggerito sopra, ma solo attraverso il wrapping nell'operatore.
C'è una piccola differenza. Se improvvisamente appare un oggetto non convertito in myclass, allora senza dynamic_cast ci sarà un errore di esecuzione, e con esso, si otterrà NULL in cambio. Se lo indirizzate con .x immediatamente, causerà comunque un errore di esecuzione, quindi non dovete preoccuparvi =)))
Se facciamo quello che ci ha ordinato il dottore dovremmo restituire qualcosa come un'istanza di classe speciale creata per la gestione degli errori ))))
P.S. Ho controllato la velocità di dynamic_casta recentemente, rispetto al solito casting - era quasi la stessa in caso di uguaglianza della classe con quella prevista.
P.S.S. In ogni caso, i for sembrano piuttosto tristi - quando si lavora con le liste si dovrebbero usare cicli come for each (come il mio ciclo)non passa il compilatore: '[' - nome atteso tst_cast.mq4 32 15
...
Cosa abbiamo effettivamente ottenuto con questo involucro? Un dynamic_cast inutile quando non è assolutamente necessario? Il wrapper stesso ha una conversione esplicita in CMyClass. Cioè ha 0% di carico di lavoro mentre il codice è più complicato (l'operatore di riferimento all'indice è usato come un operatore cast esplicito per la classe che viene passata - beh, non è affatto ovvio).
P.S.S. In ogni caso, i for sembrano piuttosto tristi - quando si lavora con le liste, si dovrebbero usare cicli come for each (come il mio ciclo)
Scusa, ma è una cosa stupida.
Quello che hai scritto è solo un uso implicito dello stesso:
Cioè un tale puntatore anonimo, ma fondamentalmente solo zucchero sintattico. Non c'è quasi zucchero in MQL, quindi non si può fare così. Ma dovrei sottolineare che il casting al discendente va avanti senza controlli e conversioni, quindi non è chiaro perché il lavoro esplicito con il puntatore sia così fastidioso.
Sì, lo capisco, sono ancora confuso con la sintassi in MQL quando si lavora con i puntatori, sembra la stessa del C++ standard, ma sono costantemente confuso e non posso né scrivere qualcosa subito, né leggere correttamente il codice della libreria dal pacchetto standard MT.... Mi sono strappato tutti i capelli! ... ma ancora sul .opera! )))) - Lo scoprirò comunque ;)
C'è una differenza, una piccola differenza. Se capita che ci sia un oggetto non convertito in myclass, senza dynamic_cast ci sarà un errore di esecuzione, e con esso si otterrà solo NULL in cambio. Che comunque causerà un errore se lo indirizzate con .x immediatamente
Capisco tutto questo, e non è una differenza da poco, dirò sinceramente che il codice di un programmatore professionista differisce da uno dilettante proprio in questa differenza - nel controllare gli errori critici ..... anche se con le tendenze moderne nei linguaggi di programmazione è stato semplificato per i programmatori più pigri usando try eccetto finally etc. ;)
Mi dispiace, ma questo è sciocco.
Oh, per favore.
Sì, ho capito tutto, non riesco a capire la sintassi in MQL quando si lavora con i puntatori, sembra essere la stessa del C++ standard, ma sono costantemente confuso e non posso né scrivere qualcosa subito, né leggere correttamente il codice della stessa libreria dalla consegna standard MT.... Mi sono strappato tutti i capelli! ... ma ancora sul .opera! )))) - capirlo ;)
Prendere C++ come punto di riferimento in caso di MQL non funzionerà :) Il volume di ciò che è impossibile in MQL è molto più grande del volume dei costrutti "compatibili". Imho, MQL è più simile a un C# molto troncato con una completa mancanza di zucchero sintattico.