Newsgroup: it.comp.lang.c++
Titolo: [sega mentale] Ridondanza variabili vs leggibilità codice

Ciao NG,
E' un po' che volevo fare questa domanda ma poi il
quotidiano la relega (giustamente, perché non sono
un programmatore) in un angolo della memoria. Ora è
il momento.
Spesso capita di aver bisogno di due o più variabili
dello stesso tipo (int, float, etc) che fanno cose
diverse ma non contemporaneamente. Finché sono
contatori interi io dichiaro i vari "ic", "jc", "kc"
eccetera e li riutilizzo a man bassa perché il senso
è chiaro anche a primissima vista. Ma quando per
esempio, so che con N float posso fare tutto quel
che mi serve, io parto sparato con cose tipo
"fdummy1", "fdummy2" eccetera, e li riuso con
significati molto diverse in sottosezioni diverse
della mia routine. Escludendo i casi ovvi di
variabili che per fortuna hanno una funzione molto
specifica, a cui posso dare nomi significativi, è
ovvio che si pone il problema di bilanciare
leggibilità e spreco di variabili.
Purtroppo sono "nato" con l'assembler sul vecchio
8088 e non riesco a levarmi di testa l'idea che
posso chiedere centinaia di mega al SO o
dimensionare stack della cui ampiezza "non mi rendo
conto" e che sarà sempre superiore a quanto posso
immaginare. Razionalmente lo so; ma emotivamente
qualsiasi spreco mi dà un fastidio enorme e per
quanto sia ridicolo non riesco a sradicarmi da
questo tipo di falsa economia. Mi direte che è il
problema a contare. Se devo fare una routine che va
in multithreading con centinaia di threads è un
conto (BTW mi sta proprio accadendo e ho
risolto con una sola variabile che punta a una
struttura allocata dinamicamente). Se ho un
programma semplice e piccolo è altro. Ma non so
regolarmi. Ci sono criteri, indicazioni e magari
raccomandazioni pubblicate che sono di fatto uno
standard?
Non ditemi che sono OT perché credo siano cose
abbastanza legate al tipo di approccio comune che
probabilmente hanno sia il linguaggio che la media
dei compilatori. :)
ciao!
Apx.
-- 
"La teoria è sapere come funzionano le cose e
non sapere come farle funzionare; la pratica è
sapere come far funzionare la cose senza sapere come
funzionano; il nostro scopo è unire la pratica
alla teoria per riuscire a non far funzionare
le cose senza capire come abbiamo fatto"

 leggibilità e spreco di variabili.
Prediligere la leggibilità del codice alla performance è sempre cosa
buona, specie coi processori del giorno d'oggi. Se fra 6 mesi devi
metterci le mani... brrr.
Comunque, vedo due problemi:
* se ti capita così spesso di dover riutilizzare variabili all'interno
di metodi, stai probabilmente scrivendo metodi troppo lunghi; dovresti
spezzarne la funzionalità in più funzioni separate.
* stai pensando che il compilatore non sia abbastanza intelligente da
accorgersi che può riutilizzare lo stesso spazio sullo stack.
Il GCC, per quanto ne so, sfrutta la dichiarazione al primo uso delle
variabili per aiutarsi con il loro reimpiego, e comunque con la
rappresentazione in albero SSA ha tutte le informazioni ad esso
necessarie. Al massimo, puoi forzare parzialmente la visibilità delle
variabili all'interno della funzione introducendo blocchi anonimi.
E.g.:
if (int i = 0; i < a.size (); i++)
{
  int a = 1;
  // scope di "i" e "a"
  {
    // scope con "i", "a" e "b"
    int b = 2;
  }
  {
    // scope con "i", "a" e "c"
    int c = 3;
  }
  // scope con "i" e "a"
}
Un buon compilatore sa cosa fare.
Ciao,
Matteo

 Non ditemi che sono OT perchï¿œ credo siano cose
Non ï¿œ OT, anzi ï¿œ sempre interessante.
ciao.

 struttura allocata dinamicamente). 
Ecco, una roba cosi' e' *probabile* che sia indice di pesanti difetti
architetturali. Non e' *certo*, ovviamente, ma un centinaio di thread in
un modello a stato modificabile sono verosimilmente un problema,
certamente un incubo da debuggare e ragionevolmente portano a forti
inefficienze ogni volta che devi sincronizzare/accedere a stato
condiviso.
-- 
-riko

 sincronizzare/accedere a stato condiviso.
Giusta osservazione; nel mio caso il problema è
questo: ho un sistema che evolve da un istante
temporale a un altro in dipendenza da qualche
centinaio di sistemi di equazioni differenziali ed è
la fisica del problema che è così ed è
insormontabile. Occorrerebbe pensare a un livello
più alto; per capirci lo stesso tipo di
considerazioni che ha portato alla fisica
statistica. Ma per ora non è questo il caso. Visto
il tipo di problema io ho semplicemente
parametrizzato la cosa con una variabile che
contiene il numero di sezioni da mandare in
parallelo. Divido il numero di equazioni per quel
numero e so quante equazioni si becca ciascun
"processo" (per adesso non ho utilizzato cose
sofisticate come code o procedure per bilanciare
l'esecuzione perché prima devo capire se l'accrocco
funziona). Non ho usato la parola "thread" perché ho
wrappato tutto tramite funzioni di astrazione per
parallelizzare il tutto. Ora le funzioni wrap non
fanno altro che usare i posix ma un domani... chi sa
come saranno le architetture e le CPU. Non mi sogno
di mandare in esecuzione 200-1000 threads,
ovviamente :) Comunque è una sezione di 50 linee di
codice, ed è localizzata solo lì, per il resto per
mia fortuna il calcolo è intrinsecamente sequenziale.
Grazie ancora a tutti voi!
