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
L'errore di template mismatch dovrebbe probabilmente verificarsi in fase di compilazione.
Ma nella situazione in cui c'è un oggetto array
Tale errore non dovrebbe verificarsi perché nel primo caso la chiamata di Array[int] è usata come parametro sinistro dell'operazione = e non è una variabile di tipo double, mentre nel secondo caso è quella destra, e il parametro sinistro è una variabile di tipo double.
Non si sente, non dovrebbe fare nulla - il sovraccarico di tipo è vietato ed è esplicitamente scritto in C++ standard (e µl come C++ simile - probabilmente anche):
La probabile ragione è spiegata sopra. Quindi il tuo operatore[] non è valido.
Non si sente, non dovrebbe fare nulla - l'overloading per tipo è vietato ed è esplicitamente scritto nello standard C++:
La probabile ragione che ho dato sopra. Quindi i vostri operatori[] non sono validi.
Non ti stavo rispondendo sullo standard, ma sulla logica basata sul buon senso. La vostra definizione di causa "probabile" non invalida i miei argomenti. La possibilità di sovraccaricare un'operazione di digitazione (anche implicitamente) non contraddice la norma che hai citato, perché è l'operazione di casting a un particolare tipo esplicitamente definito dal contesto che è sovraccaricata.
Forse non sono stato troppo chiaro, ma con questa precisazione spero che sia più chiaro.
P.S. Naturalmente, il mio codice fittizio contraddice lo standard. Ma se avete bisogno di decifrarlo (perché stavo cercando di capire da solo come formulare la domanda in modo più accurato), dovrebbe essere così:
Se sostenete l'operatore type(), bene. Se tu sostieni l'indentazione dai plus, allora io sono contrario (permettendo l'overloading per tipo di ritorno) per risolvere qualche problema particolare (che sicuramente può essere risolto in modo diverso e più bello - in qualche modo non sono mai stato contorto in questo modo come nel primo post).
Sì, alla fine sono a favore dell'introduzione dell'operatore di digitazione. Perché risolve esattamente il problema, che ho dichiarato nel post iniziale, solo in un modo più "convenzionale" (adatto agli standard, e probabilmente più corretto in generale).
P.S. Naturalmente il mio codice inventato è contro lo standard.
Perché è contraddittorio, in più è abbastanza valido. E in mql non ci sono affatto banchine.
Perché originariamente c'erano due funzioni operator[] identiche con un tipo di ritorno diverso (l'ho corretto nella seconda versione). Questo è vietato dalla norma. Non è vietato digitare (anche implicitamente), solo che non hanno ancora avuto il tempo di implementarlo. Tenendo conto dell'impressionante tasso di sviluppo di mql5, sono sicuro che sarà implementato prima o poi. Soprattutto se qualcun altro oltre a me ci fa caso sul forum...
Perché c'erano due funzioni operator[] identiche con un tipo di ritorno diverso. Questo è vietato dalla norma. Non è vietato digitare (anche implicitamente), semplicemente non hanno ancora avuto il tempo di implementarlo. Tenendo conto della grande velocità di sviluppo di mql5 sono sicuro che sarà implementato prima o poi. Soprattutto se qualcun altro oltre a me vi presterà attenzione sul forum...
Intendo l'ultimo codice - va bene.
Intendo l'ultimo codice - va bene.
Va bene, ma non funziona ancora in mql5. Seguiamo e speriamo nelle innovazioni di mql5. È questa incapacità di implementare adeguatamente un oggetto array, a causa dell'impossibilità di gestire un tipo utente allo stesso modo di un array ordinario, che mi ha preoccupato personalmente per molto tempo. Quando si crea il proprio array, questo risulta essere difettoso fin dall'inizio, non possedendo le stesse proprietà di usabilità di quelli integrati.
Va bene, ma non funziona ancora in mql5. Seguiamo e speriamo nelle innovazioni di mql5. È questa incapacità di implementare adeguatamente un oggetto array, a causa dell'impossibilità di gestire un tipo utente allo stesso modo di un array ordinario, che mi ha preoccupato personalmente per molto tempo. Quando si crea il proprio array, inizialmente risulta essere difettoso, non avendo la stessa usabilità di uno integrato.
Beh, non mi aspetto grandi miracoli, il linguaggio non viene più sviluppato, dubito che aggiungeranno un operatore fantasma. Qui sono specificamente stressato dall'impossibilità di farlo in questo modo:
ma è inutile dirlo, credo.
Beh, non mi aspetto grandi miracoli, il linguaggio non è più molto sviluppato, dubito che aggiungeranno un operatore fantasma. Ciò che mi preoccupa in particolare è l'impossibilità di farlo in questo modo:
Ma è inutile parlarne, credo.
Non è del tutto chiaro quale sia il problema. L'inizializzazione dell'oggetto non potrebbe essere implementata in un metodo separato come Init(), forse anche in uno virtuale?