Caratteristiche del linguaggio mql5, sottigliezze e tecniche - pagina 213

Nuovo commento
 
A100 #:

E non c'è bisogno di cambiare il comportamento delle funzioni esistenti - è sufficiente aggiungere nuove funzioni corrette (con qualche prefisso/suffisso) e dichiarare le precedenti obsolete con un avviso corrispondente

Distruggere l'intero senso di FileReadArray? Pensate a queste funzioni come a un backup di un pezzo di memoria. Solo byte.

 
fxsaber #:

Distruggere l'intero punto di FileReadArray? Pensate a queste funzioni come a un backup di un pezzo di memoria. Solo byte.

Quindi vuoi prima crearti delle difficoltà attraverso il privato, il cost e poi superarle eroicamente attraverso l'accesso "diretto" alla memoria?

Io ho un approccio diverso - se si presenta una tale necessità, significa che il programma è stato progettato in modo improprio fin dall'inizio

 
A100 #:

Vale a dire che lei propone di creare prima delle difficoltà per se stesso attraverso il privato, const

Ottengo sempre un grande beneficio dal privato/const. Permettono di controllare molto bene l'architettura del programma.

e poi eroicamente superarli con un accesso "diretto" alla memoria?

Nessun superamento. Tutto è molto semplice e logico.

Il mio approccio è diverso - se si presenta una tale necessità, significa che il programma è stato progettato male fin dall'inizio.

Capisco che sono pronti a scrivere tutto in un heap (senza private/const), privando la comodità del controllo architettonico per il bene della "purezza" dell'OOP.

 
Ilyas #:

Il file... apparso quando la privacy e la costanza non esistevano, non abbiamo ancora pensato a cambiare questo comportamento, perché non lo consideriamo critico.

CharArray<->Struct sono apparsi recentemente, ma funzionano bene con private/const. Speriamo che non vengano rivisti.

 
Per la pulizia del codice, i metodi di serializzazione e deserializzazione dovrebbero essere scritti per le strutture. Allora non ci sarà alcun conflitto di privacy, e i campi costanti non sono costanti se possono essere cambiati durante la deserializzazione
 
fxsaber #:

Capisco che siete pronti a scrivere tutto in un heap (senza private/const), privando la comodità del controllo architettonico per il bene della "purezza" dell'OOP.

Hai frainteso - dal punto di vista OOP l'oggetto è autosufficiente (non ha bisogno di funzioni esterne) - quindi non c'è conflitto con il privato. E se c'è un conflitto con la costituzione, come giustamente notato:

Siete voi che li avete resi artificialmente così
 
fxsaber #:

Capisco che siete pronti a scrivere tutto in un heap (senza private/const), privando la convenienza del controllo architetturale per il bene dell'OOP "puro".

Siete disposti a usare qualsiasi scappatoia dell'accesso diretto alla memoria per convenienza invece di usare un approccio canonico meno conveniente ma più sicuro.

 
TheXpert #:

piuttosto il contrario. siete disposti a usare qualsiasi scappatoia dell'accesso diretto alla memoria per convenienza invece di usare il meno conveniente ma più sicuro approccio canonico.

Due richieste:

  1. Mostra il codice per salvare e caricare la struttura.
  2. Un esempio dei pericoli dell'approccio non canonico.
 

Beh, questo è un bug feroce. Esempio:

class C{
   static uint count;
   const uint number;
public:
   C():number(++count){PrintFormat("C[%i]",number);}
  ~C(){PrintFormat("~C[%i]",number);}
   uint Number() const {return number;}
};
uint C::count=0;

void OnStart()
{
  C c[3]={};
  for(int i=0;i<ArraySize(c);Print(c[i++].Number()));
}
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]

La memoria viene allocata, il distruttore viene chiamato quando viene rilasciato (il che suggerisce il comportamento atteso secondo RAII), ma il costruttore viene dimenticato per essere chiamato quando l'oggetto viene creato))

 

Non l'ho mai visto prima.

1...206207208209210211212213214215216217218219220...247
Nuovo commento