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
Scrivo così perché mi piace. Detto questo, diventa davvero brutto quando si fa il debug.
Anche in questa espressione.
è difficile capire chi ha restituito cosa. In quelli più complessi (lo pratico sempre) è davvero difficile.
Se vuoi usare 2-3... Supponiamo 5 risultati dell'esecuzione di funzioni unite da operazioni logiche (o operatore condizionale ternario) - l'ho visto su githab o da qualche altra parte, questo codice può essere gestito
Ma se hai una dozzina di queste "chicche"... imho, non è pratico
Non sono uno sviluppatore di mql, ovviamente,
ma in C switch genera una ricerca binaria abbastanza efficiente e non causa paginazione inutile o scarico della cache. Quindi sì, spesso è meglio dell'indirizzamento indiretto tramite array e strutture.
gli sviluppatori hanno scritto da qualche parte e qui informazioni simili
ha trovato solo questo:
Forum sul trading, sistemi di trading automatico e test di strategia
Questo è l'articolo che abbiamo trovato in MQL5.
Slava, 2011.04.14 09:59
No, purtroppo no. Per i tipi di stringa solo se ... altrimenti se ... else
L'uso di tipi interi in switch velocizza il codice dell'analizzatore diverse volte di più che se
Ma se sono una decina... imho, non è pratico.
Piccolo mostro.
Leoperazioni logiche permettono di scrivere in modo succinto quando si usano diverse impostazioni tramite macro. Ma è un orrore, ovviamente.
Leoperazioni logiche permettono una scrittura concisa quando si utilizzano varie impostazioni tramite macro. Ma è un orrore, ovviamente.
Il tuo esempio di "il fine giustifica i mezzi"
lamia domanda riguardava uno stile molto diverso e incomprensibile
Il piccolo mostro.
A caval donato non si guarda in bocca. Ma ecco un altro paio di esempi di codice di altre persone, che mi hanno dato alcune indimenticabili decine di minuti di debugging. Forse qualcuno riconoscerà il proprio codice.
Non so se è stato facile scriverlo così, ma è irreale debuggarlo, tanto più leggerlo. E non vedo alcuna ragione oggettiva per scriverlo in quel modo.
E non vedo alcuna ragione oggettiva per scriverlo in quel modo.
Sono soggettivi, ovviamente. Non mi piacciono le variabili inutili e i ritorni multipli. Per qualche ragione, credo che EX5 sarà più breve ed eseguito più velocemente senza di loro.
Sono soggettivi, ovviamente. Non mi piacciono le variabili inutili e i ritorni multipli. Per qualche ragione credo che EX5 sarà più breve e più veloce senza di loro.
A proposito, questa fiducia che il codice sarà più breve e più veloce non è giustificata.
ecco qui
e questo
return A()||B()||X();
Sono sicuro che sarà lo stesso in velocità (e forse in dimensione del codice e della memoria utilizzata).
È solo che la seconda variante è più veloce da scrivere e tutti la scrivono e poi, quando è necessario aggiungere/complicare qualcosa, lasciano la seconda variante ma gonfiata a una difficile da leggere.
Dovreste eseguire periodicamente il refactoring in questo senso e non avrete problemi.
Fate periodicamente il refactoring in questo senso e non ci saranno problemi.
Solo per coloro che hanno molto tempo libero o sono oggettivamente così pressati che non c'è un posto dove andare senza.
Quando c'è molto ritorno, il codice sarà al 100% diverso.Solo per coloro che hanno molto tempo libero o sono oggettivamente così pressati che non c'è un posto dove andare senza.
ZS Quando c'è molto ritorno, il codice sarà al 100% diverso.Capisco, ma in parte sono d'accordo, penso solo che tutti abbiano sperimentato tempi relativamente lunghi per la risoluzione dei bug, che sarebbero trovati più velocemente se il codice fosse "perfettamente pronto" per il debug.
Non è chiaro cosa mangia più tempo - scrivere più a lungo il codice "utilizzabile" o fare il debug e trovare i bug, è sempre diverso credo.
Quando c'è molto ritorno, il codice sarà diverso al 100%.
C++ VS2019 sotto debugger
codice sorgente:
debugger asm
ridotto da comandi una chiamata solo in 2 colonne per non contare:
come potete vedere qui e i comandi si ripetono quasi l'un l'altro, è chiaro che nel primo test è necessario aggiungere qualche altro ritorno
con il 99% di fiducia, penso che a livello di processore questi codici gireranno alla stessa velocità fino a un clock - nell'ottimizzazione del processore, il parallelismo e chissà cos'altro funziona a livello di microcomandi