Perché valenok2003 è contro MT5 - pagina 2

 
Zhunko:

О! È 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.

 
IgorM:

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.

sergeev:

Ciao a tutti.

Il codice dell'assemblatore non conosce altri modi.


Non stiamo parlando di assembler :-)
 
Zhunko: Per l'uscita anticipata dai loop annidati, per passare da condizioni diverse allo stesso punto? Semplifica il codice. Lo uso spesso. A volte lo uso per i loop.

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

 

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.

 
Edsger W. Dijkstra è uno di quegli uomini il cui nome è associato alla trasformazione della programmazione da sciamanesimo a scienza(*).
 
È, naturalmente, molto limitato - un vincitore del premio Turing
 
Zhunko:

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.

sand:


Immaginate un programma di almeno 500 linee, con un centinaio di etichette e transizioni.

I driver sono ancora scritti in questo modo. Perché?
 
Zhunko:

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?