Non è lo stesso diPrint(ColorToString(Color&(uint(-1)&65535)|(230<<16)); ?
Per il risultato sì, per l'azione no.
Temo che mi scervellerò a studiare i vostri codici.
Cioè, voglio dire che tutto nei vostri metodi è delizioso (non scherzo) tranne l'abbondanza di lettere maiuscole con underscore e operazioni di risoluzione del contesto:)
Penso che se (operazione di risoluzione di un contesto) sarà permesso di sovraccaricare, voi e le vostre biblioteche andrete in astrale :lol:
È difficile non scrivere una libreria, ma crearne una utilizzabile.
Per risultato sì, per azione no. // beh, sì, per azionePrint(ColorToString(Color=(Color&(uint(-1)&65535)|(230<<16)))); :)
È difficile non scrivere una libreria, ma crearne una utilizzabile. // Entrambi sono difficili se non si ha tanta esperienza nelle peculiarità del terminale come te :)
Capisco che tutto è universale. Abbiamo risolto il problema della copia delle strutture nel prossimo thread insieme :) Non sto affrontando questo problema al momento. E mi occupo anche della costruzione di dati di vari tipi a partire da byte e della modifica di campi di bit, anche se il numero è opzionale, senza particolare profitto pratico :)
Capisco che con te tutto è universale. Abbiamo risolto il problema di copiare le strutture insieme in un thread vicino recentemente :) Non sto affrontando questo problema al momento. E mi sono occupato molto della costruzione di dati di vario tipo a partire da byte e della modifica di campi di bit, anche se il numero di opzionali, senza alcun particolare uso pratico :)
Volevo solo dire che è possibile creare A(Object)[Index] = 5.
Naturalmente, se si lavora con tutto come un unico tipo - insiemi di byte o bit o ints, ecc, allora si può, ma questo è di un altro piano, non si tratta di fare codice semplice, intuitivo, facile da capire e modificabile.
Mi piace anche quando non c'è differenza tra int, double e datetime. Ecco, forse a qualcuno piacerà l'idea (in termini di velocità di assegnazione non effettivamente diversa dai tipi originali):
#property strictclass price{ public:
intoperator| (double p){return(int)(p*100000);}
doubleoperator| (int p){return(double)p/100000.0;}};
class time{ public:
intoperator| (datetime p){return(int)uint(p);}
datetimeoperator| (int p){return(datetime)uint(p);}};
price f;
time t;
voidOnStart()
{
int bid = f|Bid, ask = f|Ask, time1 = t|TimeCurrent(), time2 = t|TimeLocal();
Print("Bid = ", f|bid, " Ask = ", f|ask, " Current time = ", t|time1, " Local time = ", t|time2);
}
Funzionerà garantito per il forex (prezzi non superiori a 21474 interi) e le date fino al 2107.
Non è lo stesso diPrint(ColorToString(Color&(uint(-1)&65535)|(230<<16)); ?
Per il risultato sì, per l'azione no.
Temo che mi scervellerò a studiare i vostri codici.
Cioè, voglio dire che tutto nei vostri metodi è delizioso (non scherzo) tranne l'abbondanza di lettere maiuscole con underscore e operazioni di risoluzione del contesto:)
Penso che se (operazione di risoluzione di un contesto) sarà permesso di sovraccaricare, voi e le vostre biblioteche andrete in astrale :lol:
È difficile non scrivere una libreria, ma crearne una utilizzabile.
Per risultato sì, per azione no. // beh, sì, per azionePrint(ColorToString(Color=(Color&(uint(-1)&65535)|(230<<16)))); :)
È difficile non scrivere una libreria, ma crearne una utilizzabile. // Entrambi sono difficili se non si ha tanta esperienza nelle peculiarità del terminale come te :)
No, non è affatto l'algoritmo utilizzato. La libreria non si preoccupa del tipo di variabile.
No, non è affatto l'algoritmo utilizzato. La libreria non si preoccupa del tipo di variabile.
Non è il tipo di variabile, ma il suo nome=, cioè l'assegnazione. L'azione e il risultato sono gli stessi - la variabile viene cambiata.
Non mi sono addentrato molto nella biblioteca però, quindi perdonatemi se qualcosa è sbagliato.Non è il tipo di variabile, ma il suo nome=, cioè l'assegnazione. L'azione e il risultato sono gli stessi - la variabile viene cambiata.
Anche se non mi sono addentrato molto nella biblioteca, quindi perdonatemi se qualcosa è sbagliato.Potete sostituire, per esempio, MqlTick-variable con una variabile intera.
Potete sostituire, per esempio, una variabile MqlTick con una variabile intera.
Capisco che tutto è universale. Abbiamo risolto il problema della copia delle strutture nel prossimo thread insieme :) Non sto affrontando questo problema al momento. E mi occupo anche della costruzione di dati di vari tipi a partire da byte e della modifica di campi di bit, anche se il numero è opzionale, senza particolare profitto pratico :)
Capisco che con te tutto è universale. Abbiamo risolto il problema di copiare le strutture insieme in un thread vicino recentemente :) Non sto affrontando questo problema al momento. E mi sono occupato molto della costruzione di dati di vario tipo a partire da byte e della modifica di campi di bit, anche se il numero di opzionali, senza alcun particolare uso pratico :)
Quindi, è possibile creare A(Object)[Index] = 5.
Volevo solo dire che è possibile creare A(Object)[Index] = 5.
Naturalmente, se si lavora con tutto come un unico tipo - insiemi di byte o bit o ints, ecc, allora si può, ma questo è di un altro piano, non si tratta di fare codice semplice, intuitivo, facile da capire e modificabile.
Mi piace anche quando non c'è differenza tra int, double e datetime. Ecco, forse a qualcuno piacerà l'idea (in termini di velocità di assegnazione non effettivamente diversa dai tipi originali):

Funzionerà garantito per il forex (prezzi non superiori a 21474 interi) e le date fino al 2107.Mi piace anche quando non c'è differenza tra int, double e datetime.
Cioè, se vi capita di confondere le mosche con le cotolette, per rendere il più difficile possibile individuare il problema?