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
О! È di nuovo goto! Lo adoro! Potete farne a meno. Si può sempre, ma non è necessario.
In alcuni casi i goto semplificano il codice e lo velocizzano. Ho letto un articolo da qualche parte che i driver sono scritti con esso per accelerare le transizioni.
Ciao a tutti.
Il codice dell'assemblatore non conosce altri modi.
Semplificare il codice è improbabile, renderlo illeggibile per gli altri è certo, sulla velocità - dipende da quali compiti, e chi ha quale "scrittura quando si programma", in linea di principio, non voglio nemmeno discutere, sembra che abbiamo discusso seriamente su benefici e danni di goto http://www.gamedev.ru/flame/forum/?id=69459.
Se si scende al livello di disassemblaggio del programma, i cicli in tutti i JVS saranno molto probabilmente organizzati come transizioni jcxz condizionali e così via..,
che sarà essenzialmente un costrutto if(cx==0) goto label
Per l'uscita anticipata dai loop annidati, per saltare da diverse condizioni a un unico punto? Questo semplifica il codice. Lo uso abbastanza spesso. A volte lo uso per i loop.
Ciao a tutti.
Il codice dell'assemblatore non conosce altri modi.
Se è così, allora è così :), come dice il detto: "tutti i colori a pennarello sono diversi!" ))))))))
La questione è individuale, vedete, lo sviluppatore principale è infastidito da OOP. Se non usasse OOP, avrebbe solcato il Gran Teatro MQL5 molto tempo fa.
http://khpi-iip.mipk.kharkiv.edu/library/extent/dijkstra/pp/ewd215.html
За многие годы я утвердился во мнении о том, что квалификация программистов - функция, обратно зависящая от частоты появления операторов go to в их программах.
...dovremmo fare... tutto il possibile per colmare il divario concettuale tra un programma statico e un processo dinamico, per rendere il più possibile evidente la corrispondenza tra il programma (che si svolge nello spazio del testo) e il processo (che si svolge nel tempo).
http://khpi-iip.mipk.kharkiv.edu/library/extent/dijkstra/pp/ewd215.html
Questa è solo una delle tante opinioni. Ci sono altrettanti pro e contro. È una questione di gusto e di stile.
L'autore si sta gravemente limitando.
Questa è solo una delle tante opinioni. Ci sono tanti favorevoli quanti contrari. È una questione di gusto e di stile.
L'autore si sta limitando molto.
Le tendenze moderne della programmazione sono tali che i programmi sono spesso scritti e accompagnati da squadre di programmatori. Questo impone requisiti sulla qualità del codice, la sua leggibilità.
La mia opinione: il codice deve essere chiaro e ben commentato. Di nuovo la mia opinione personale: go to è un operatore dannoso, impedisce di leggere il codice. Immaginate un programma di almeno 500 linee, con un centinaio di etichette e salti a esse.
La questione dell'applicazione del goto è nel campo delle preferenze personali. Non gli piace e se ne esce con una ragione per cui non gli piace.
Ci sono altri a cui piace e che hanno una ragione per cui gli piace. Per me, tutte queste ragioni sono le stesse. Il mio codice è semplificato quando il goto è applicato, allora lo uso, altrimenti non lo uso.
Non mi limito alle speculazioni degli altri.
Immaginate un programma di almeno 500 linee, con un centinaio di etichette e transizioni.
I driver sono ancora scritti in questo modo. Perché?
Perché la velocità di esecuzione viene prima, seconda e terza nei piloti.
Perché abbiamo bisogno di linguaggi di alto livello quando possiamo scrivere tutto in linguaggio assembly?
E perché non mettono stereo portatili e sedili convertibili in Formula Uno?