On 24 Nov 2002 at 23:40, Davide Bolcioni wrote:
> Mettilo in una funzione, convinciti che è efficientissimo e non pensarci
> più. Se usando il profiler scoprirai che il collo di bottiglia è lì, ci
[snip]
> Non è questione di cieca fiducia, è questione di astrazione. Ovvero, il
> codice di libreria fa certe promesse e si riserva di implementarle come
> meglio riesce. Magari c'è un baco, ma sarà corretto. Per decisioni
> *importanti*, ad esempio uso un vettore o una lista, si incapsulano in
> una classe; decisioni con conseguenze più estese richiedono versioni
> distinte dello stesso sorgente.
No... non ci siamo capiti. Non è questione di efficenza principalmente.
Eg. io scrivo in C... gcc riscrive in linguaggio macchina
_ottimizzato_, il processore cerca di riottimizzare l'esecuzione
parallelizzando, rivertendo l'ordine di esecuzione, branchprevedendo
etc...
Io ho scritto _una_ cosa, ho pensato _una_ cosa e la catena gcc...
processore cerca di fare _quella_ cosa che io ho descritto in C.
Io evito di occuparmi dei dettagli.
Più o meno come chiedere:
vorrei un minestrone
piuttosto che:
vai a comperare i fagioli, le verze, la gallina.... bla bla bla...
questo è bene(tm)
Un altra cosa è:
vai a comperare patate, zucchine e biancostato, falle bollire...
aggiungi la pasta etc...
piuttosto che
vai a comperare fagioli, verze, la gallina, falle bollire insieme al
riso...
Viene fuori il minestrone ma io stavo chiedendo 2 cose diverse.
E le penso in maniera diversa.
questo è male(tm)
Un conto è dimmi la dimensione del file e il compilatore o chi per esso
trova il sistema di farmela sapere.
Un conto è che io penso e scrivo che deve aprirlo andarci in fondo e
dirmi dove è arivato.
Posso fare una classe di equivalenza tra tutte le
ottimizzazioni/pessimizzazioni [yuk] possibili partendo dallo stesso
codice.
Posso fare delle classi di equivalenza tra alcune strutture su diversi
linguaggi (cicli, salti, assegnazioni...).
Non posso fare una classe di equivalenza tra scopi del codice perchè il
compilatore capisce il cosa ma non il perchè.
E per me il perchè è importante anche per _pensare_ al codice che
scrivo.
Allora o non è possibile astrarre "dimensione del file", o nessuno lo
ha ancora fatto. Ma dammi la dimensione del file non è equivalente a
aprilo, vai in fondo e desumi la dimensione del file.
stat è uno, il giro di tellg seekg è l'altro.
La soluzione "ficca in una funzione" risponde sia a non è possibile
astrarre sia a nessuno lo ha mai fatto.
Se non è possibile astrarre tu ai fatto un bel wrapper che da
dimensione del file e hai isolato dallo standard C/C++ qualche cosa che
può essere dipendente dall'architettura o altro, se è nessuno lo ha mai
fatto... lo ficco li, lo scrivo alla meglio e _poi_ vedrò di scrivere
una soluzione generale.
Ma nascondere la polvere sotto il tappeto perchè ci sono cose più
importanti da fare (cosa legittima... ma fino a un certo punto) sul mio
vocabolario non è la definizione di astrarre :)
Tra le altre cose se poi le cose vanno male non posso nemmeno dare la
colpa agli autori delle librerie... perchè la polvere sotto il tappeto
ce la ho messa io ;)
> Tra parentesi, il motivo per cui è importante non chiamare seek() ad
> ogni invocazione è che una system call è nettamente più pesante di una
> chiamata di funzione ordinaria. In Linux la cosa è meno penalizzante che
> p. es. in Solaris, ma comunque c'è.
stat è una system call diretta.
tutto il traffico di tellg() seekg() etc... ne potrebbe nascondere un
numero >=1.
> Non li ho letti, ora sto leggendo:
> Nicolai Josuttis, "The Standard C++ Library"
sentito vagamente... elogiato da altri... vaghissimo ricordo
> e il prossimo di C++ in coda è
> A. Alexandrescu, "Modern C++ Design"
mai sentito
Terrò presente... domani passo dal mio pusher ;)
danke
--
Salve
Ivan Sergio Borgonovo
http://www.webthatworks.it/
uniq life || sleep 24h
|