Errori, bug, domande - pagina 2521
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
fxsaber:
Подскажите, как в C++ с этим? Задумался, использовать эту фишку в своем коде или нет. Если в C++ работает, буду использовать. Нет - вряд ли, т.к. могут отменить в следующих билдах.
b = a; a = b; // OKIl primo incarico funziona solo in MQL. Ed è un peccato che funzioni. Vorrei che finalmente abolissero questo equivoco. Non ci sono problemi con la seconda.
Il primo incarico funziona solo in MQL. Vorrei che finalmente cancellassero questo equivoco, non ho problemi con il secondo.
Questo è strano. Ho pensato che il primo deve funzionare e il secondo no.
Questo è strano. Ho pensato che il primo deve funzionare e il secondo no.
Beh, a quanto pare, gli sviluppatori di MQL non capiscono bene l'essenza dell'assegnazione. Perché è da molto tempo che parlo di questo problema, ma si scontra con un muro.
L'essenza dell'assegnazione è che all'oggetto viene assegnato un oggetto equivalente. Significa che l'oggetto di destra è prima castato implicitamente nel tipo dell'oggetto di sinistra e solo dopo avviene l'assegnazione (copiatura). E nel primo caso tale casting (A->B) è certamente impossibile.In C++ ci sarà un errore, ma in MQL invece l'oggetto sinistro viene castato in quello destro e viene eseguito A::operator=(A&), sostituendo solo una parte dell'oggetto b. Questo è un'assegnazione?
Immaginate di assegnare int a long, ma solo i primi quattro byte vengono sostituiti e il resto non viene toccato. È lo stesso qui.
Immaginate di assegnare un int a un long, ma solo i primi quattro byte vengono sostituiti, e il resto non viene toccato. È lo stesso qui.
Quindi è conveniente, credo. Nel contesto delle strutture, ovviamente.
Quindi è conveniente, a quanto pare. Nel contesto delle strutture, ovviamente.
Può salvare i caratteri in una stringa, ma è una fonte di errori casuali e complica/distorce la comprensione del codice. Come ho già detto sopra, il segno di uguale ha un significato chiaro e inequivocabile che l'intero oggetto viene cambiato. Questo è il motivo per cui l'operatore non viene utilizzato come previsto in questo caso. Se si desidera un tale comportamento non standard, si dovrebbe sovraccaricare l'operatore per tali scopi.
p.s. L'unica eccezione è se la classe B non ha campi propri, cioè è esattamente la stessa della classe A (completamente equivalente ad essa), allora non c'è motivo di impedire questa assegnazione, anche se non funziona comunque in C++, ma in MQL si può permettere.
Nel file opt, nel chunk dove sono prescritti tutti i parametri di input, il valore per i parametri ottimizzati (definiti tramite i campi size e offset) non contiene Value (come senza ottimizzazione), ma Start.
Sarebbe logico avere Value lì.
Beh, sembra che anche gli sviluppatori MQL non capiscano bene l'essenza dell'assegnazione. Perché è da molto tempo che parlo di questo problema, ma si scontra con un muro.
L'essenza dell'assegnazione è che all'oggetto viene assegnato un oggetto equivalente. In altre parole, dello stesso tipo.
L'essenza delle operazioni per i tipi di utente non è definita in anticipo. E solo il loro ordine è definito, che in questo caso consiste nel chiamare l'operatore= appropriato.
In MQL, a differenza del C++ operator= è ereditato, quindi b = a; è equivalente a chiamare A::operator=(const A&);
In generale, non c'è contraddizione qui. Nel caso speciale dell'assegnazione di un oggetto equivalente, c'è qualche incoerenza di entità, ma non più di questo
In MQL a differenza del C++ operator= è ereditato, quindi b = a; è equivalente a chiamare b.operator=(const A&);
Beh, sì, questo è il problema. Ma la differenza di scrittura non gioca un ruolo qui. In C++ non compilerà in entrambi i casi.
In generale, non c'è contraddizione qui. Nel caso speciale di assegnazione di un oggetto equivalente, c'è una certa incoerenza di entità
Se compila, significa che l'operando di destra è implicitamente castato in quello di sinistra e poi avviene una sostituzione completa dell'oggetto, come dovrebbe logicamente funzionare. Ho fatto un esempio con int->long. E la sostituzione di parte dell'interno di un oggetto non è un'assegnazione. Quindi c'è una contraddizione e un'incoerenza tutte in una.
p.s. Anche se possiamo anche sovraccaricare l'operatore B::operator=(A&), ma suppongo che un programmatore sensato sostituirebbe l'oggetto B completamente, non parzialmente, poiché questa è l'essenza dell'assegnazione.
Se si vuole un'ortografia concisa, si potrebbe fare qualche altro operatore per questo: &= o |= per esempio. Almeno non sono usati comunemente, quindi non c'è confusione.
..........
Una contraddizione sarebbe almeno con C++. ......
..........
Cosa vi fa pensare che MQL debba essere completamente equivalente al C++?
C-like non significa equivalente!
MQL è sviluppato per compiti definiti e non è obbligato a copiare completamente il linguaggio sulla base del quale è stato creato.
La smetti di essere indignato?
Ma in Pascal potete .........
In Assembler potete andare su .....
E in Java ....
E in BASIC ....
Vi esercitate a confrontare le lingue qui?
=======
P.S. Non sei solo tu...
Cosa vi fa pensare che MQL debba essere completamente compatibile con C++?
...
Vi esercitate a confrontare le lingue qui?
Stavo rispondendo a una frase specifica. Si calmi. Prendi della valeriana e vai a letto, non ti fa bene preoccuparti. ...Alcune persone si scaldano alla parola "C++".