Dichiarare le variabili dietro il ciclo o dentro il ciclo? - pagina 9

 
Vict:

Non capisco, vero?

Dubito che non lo sapesse.

È comprensibile.

Mi piacerebbe qualcosa del genere:

.......
int tipa_var;
// бла-бла-бла
..................
// кирдык, дальше она не нужна
удаляю tipa_var
 
Сергей Таболин:

Questo è comprensibile.

Vorrei qualcosa come:

Beh, mettete i blocchi, è quello che faccio sempre.

int long_lining_var;
/*block*/ {
        int tipa_var;
        ...
} // кирдык, дальше она не нужна

O due parentesi sono troppe?)

 
Vict:

Bene e sistemare i blocchi, è quello che faccio sempre.

O due parentesi sono troppe?)

Non è solo un sacco... È come l'Everest sulla tua testa... )))))))))

Ecco cosa significa la vecchiaia - ho sempre pensato che le "due parentesi" dovessero aprirsi con qualcosa...

E che possano semplicemente "localizzare" del codice - non ne sono sicuro....

Vivi e impara! Lode ... me )))) - Sono sempre felice di imparare ciò che non sapevo.

E grazie! )))))))))

 
Igor Makanu:

1953-2008 padre

1953-2019 suocero

Le mie condoglianze. Sono un anno più giovane, o anche meno. Quindi non ho più bisogno di riempire il mio vocabolario.

 
Alexey Viktorov:

Le mie condoglianze. Sono un anno più giovane, o anche meno. Quindi non ho più bisogno di riempire il mio vocabolario.

OK

non si tratta di vocabolario, si tratta di capire che sei stato introdotto all'informatica più di 30 anni fa e c'erano linguaggi di programmazione semplici, Pascal, Basic, Fortran, Assembler e...

ma il fatto che ora usi Windows - clicca il mouse - ottieni il risultato o android/appletophone..... è merito dei programmatori che non sono seduti su vecchi linguaggi efficienti, ma stanno scrivendo molte e molte soluzioni software, grazie a OOP e altri paradigmi di programmazione

I nuovi stili di programmazione aumentano la velocità di sviluppo del software, e questo è più importante della performance, perché non è un fatto che il nuovo software sarà richiesto dal mercato (utenti), e il tempo scorre? - Quali delle aziende che sviluppano software sono pronte ad essere lo sviluppatore di un'unica soluzione software per tutta la storia dell'azienda? - Se il mercato (gli utenti) accetta l'idea di un nuovo software - allora, e solo allora, ha senso lottare per le prestazioni del software, anche se lo riscrivi in Assembler!

Gli sviluppatori di compilatori, RAD, framework e altri strumenti adattano anche i loro prodotti alle tecnologie richieste, cioè alla fine pensare che OOP sia qualcosa di terribilmente lento o usare brevi funzioni ausiliarie non è una soluzione efficace.... , e se scrivo un "pezzo di codice lineare" - sarà efficace, ma non in realtà, e molto probabilmente sarà il contrario

una tale storia ;)

 
Igor Makanu:

OK

non si tratta di vocabolario, si tratta di capire che sei stato introdotto all'informatica più di 30 anni fa e c'erano linguaggi di programmazione semplici, Pascal, Basic, Fortran, Assembler e...

ma il fatto che ora usi Windows - clicca il mouse - ottieni il risultato o android/appletophone..... è merito dei programmatori che non sono seduti su vecchi linguaggi efficienti, ma stanno scrivendo molte e molte soluzioni software, grazie a OOP e altri paradigmi di programmazione

I nuovi stili di programmazione aumentano la velocità di sviluppo del software, e questo è più importante della performance, perché non è un fatto che il nuovo software sarà richiesto dal mercato (utenti), e il tempo scorre? - Quale delle aziende che sviluppano software è pronta ad essere lo sviluppatore di un'unica soluzione software per tutta la storia dell'azienda? - Se il mercato (gli utenti) accetta l'idea di un nuovo software - allora, e solo allora, ha senso lottare per le prestazioni del software, anche se lo riscrivi in Assembler!

Gli sviluppatori di compilatori, RAD, framework e altri strumenti adattano anche i loro prodotti alle tecnologie richieste, cioè alla fine pensare che OOP sia qualcosa di terribilmente lento o usare brevi funzioni ausiliarie non è una soluzione efficace.... , e se scrivo un "pezzo di codice lineare" - sarà efficace, ma non necessariamente, e molto probabilmente sarà il contrario

questa è la storia ;)

Sono d'accordo su tutto tranne che su una cosa. MQL è un linguaggio puramente orientato al software. Allora perché cercare di spremere qualcosa che non gli serve? Non c'è motivo di cercare di elaborare alcuni calcoli il più velocemente possibile, se molti millisecondi, e a volte anche secondi, passano da tick a tick.
 
Alexey Viktorov:
Allora perché cercare di spremere da lui qualcosa di cui non ha bisogno? A cosa serve cercare di fare alcuni calcoli il più velocemente possibile, se molti millisecondi, a volte anche secondi, passano da un tick all'altro.

Alcune persone fanno il loro lavoro come in una catena di montaggio - ottengono il TOR (o la loro idea), fanno il resto - ottengono il TOR...

e alcuni sono costantemente alla ricerca di un modo per fare questo lavoro in metà tempo la prossima volta nel loro tempo libero

E alcuni sono sempre alla ricerca di un modo per accelerare l'esecuzione di ogni frammento di codice e quindi trovare la struttura di chiamata ottimale per aumentare le prestazioni

c'è solo... ognuno ha la sua strada? ))))

 
Igor Makanu:

Il fattore umano colpisce alcune persone, alcune fanno il lavoro come in una catena di montaggio - ricevono il ToR, fanno il resto - ricevono il ToR...

Alcuni sono costantemente alla ricerca di un modo per rendere questo lavoro due volte più veloce la prossima volta che hanno tempo libero

E qualcuno è costantemente alla ricerca di un modo per rendere ogni frammento di codice più veloce, e poi trovare la migliore struttura di chiamate per renderlo più veloce

Penso che ci sia solo... ognuno ha il suo modo? ))))

Tutto sommato, questa è una discussione inutile. Si perde così tanto tempo a cercare di capire cosa intendeva il cliente con questo codice che si potrebbe dover riscrivere il codice diverse volte. Quindi, quanto velocemente avete bisogno di scriverlo? Fare come ha capito e poi cercare di scoprire cosa intendeva il cliente quando si è rivolto all'arbitrato?

E in generale, parlavo solo di moderazione. Non c'è bisogno di sovraccaricare il codice in MQL, spesso con creazioni di oggetti inutili.

Ci sono molti esempi di inutilità, ma non ho più voglia di discutere questo argomento.

 
Igor Makanu:

dà fuori, stringa e stampa non è un indicatore di lavoro con le variabili

'tst.mq5' tst.mq5 1 1

possibile uso di una variabile non inizializzata 'c' tst.mq5 16 10

possibile uso di una variabile non inizializzata 'e' tst.mq5 20 17

codice generato 1 1

0 errore(i), 2 avviso(i), 526 msec trascorsi 1 3

Ok, dà fuori quando si usa esplicitamente uninitialized nei calcoli. Questo è un bene.

 
Igor Makanu:

OK

non si tratta di vocabolario, si tratta di capire che sei stato introdotto all'informatica più di 30 anni fa e c'erano linguaggi di programmazione semplici, Pascal, Basic, Fortran, Assembler e...

ma il fatto che ora usi Windows - clicca il mouse - ottieni il risultato o android/appletophone..... è merito dei programmatori che non sono seduti su vecchi linguaggi efficienti, ma stanno scrivendo molte e molte soluzioni software, grazie a OOP e altri paradigmi di programmazione

I nuovi stili di programmazione aumentano la velocità di sviluppo del software, e questo è più importante della performance, perché non è un fatto che il nuovo software sarà richiesto dal mercato (utenti), e il tempo scorre? - Quale delle aziende che sviluppano software è pronta ad essere lo sviluppatore di un'unica soluzione software per tutta la storia dell'azienda? - Se il mercato (gli utenti) accetta l'idea di un nuovo software - allora, e solo allora, ha senso lottare per le prestazioni del software, anche se lo riscrivi in Assembler!

Gli sviluppatori di compilatori, RAD, framework e altri strumenti adattano anche i loro prodotti alle tecnologie richieste, cioè alla fine pensare che OOP sia qualcosa di terribilmente lento o usare brevi funzioni ausiliarie non è una soluzione efficace.... , e se scrivo un "pezzo di codice lineare" - sarà efficace, ma non necessariamente, e molto probabilmente sarà il contrario

questa è la storia ;)

Quando sono stato assunto ho lavorato per lo più nel campo dell'embedded, dsp ecc., anche se posso fare cose di desktop e database, ora non me lo ricordo. Beh, a livello embedded passare a OOP spesso riduce le prestazioni di metà o due volte. C'è stato un sacco di lavoro con l'assemblatore, si legge il codice generato in asm e si vede che ci sono tanti gesti inutili. Ma queste sono tutte sciocchezze nella nostra realtà. Quando comprerò una scheda video decente sarò in grado di scrivere per OpenCL. Diventerò figo ))