Domanda sulla digitazione - pagina 3

Nuovo commento
 
Ilya Malev:

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):

Certain function declarations cannot be overloaded:

- Function declarations that differ only in the return type, the exception specification (18.4), or both
cannot be overloaded.

La probabile ragione è spiegata sopra. Quindi il tuo operatore[] non è valido.

 
pavlick_:

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ì:

class Array{

public:

Array *operator[] (int i){ id = i; return GetPointer( this ); }

double operator double(){ return data[i]; }

Array *operator=(double d){ data[id]=d; return GetPointer( this ); }

private:

double data[10];

int id;

};



int OnStart(){

  Array array;

  double d=123.456;

  array[5]=d;

  d=array[5];

}
 
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 probabilmente potrebbe essere risolto in modo diverso e più bello - in qualche modo non ho mai avuto modo di farlo come nel primo post).
 
pavlick_:
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).

 
Ilya Malev:

P.S. Naturalmente il mio codice inventato è contro lo standard.

Perché contraddice lo standard, è perfettamente valido nei plus. E non ci sono banchine in Mcl.
 
pavlick_:
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...

 
Ilya Malev:

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.

 
pavlick_:

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.

 
Ilya Malev:

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:

class Q {};

Q q;
// что то делаем и решаем переинициализировать q
q = Q();  // ошибка, нужно извратиться:

Q temp;
q = temp;

ma è inutile dirlo, credo.

 
pavlick_:

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?

12345678910
Nuovo commento
Motivazione: