erlug
[Top] [All Lists]

Re: [Erlug] C++ 2.95.2

To: erlug@xxxxxxxxxxxxxx
Subject: Re: [Erlug] C++ 2.95.2
From: Davide Bolcioni <db_erlug@xxxxxxxx>
Date: Mon, 25 Nov 2002 22:31:16 +0100
Ivan Sergio Borgonovo wrote:

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.

Purtroppo non è così. Tu pensi che ciò che hai scritto rispecchi ciò
che tu pensi possa portare il programma a risolvere il problema, ma
il compilatore non è così sveglio: prende ciò che hai scritto e
applica meccanicamente una serie di trasformazioni "legali" tali che,
supponendo che ciò che tu hai scritto sia "legale" ovvero non violi
la semantica del linguaggio stesso, violazione di solito non
individuabile a tempo di compilazione, il codice generato quando
eseguito darà risultati coerenti con il sorgente *entro i termini*
della definizione del linguaggio stesso. Definizione assolutamente
astratta ma anche in diversi punti imprecisa: l'unico linguaggio la
cui semantica è definita con precisione è il Prolog, se la memoria
non mi fa difetto.

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)

Questa è una libreria: come si procura gli ingredienti non ti
riguarda fino a che non scopri che ti ha vuotato le tasche per
farlo.

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)

La differenza è solo nella tua visione del problema. Per aderire alla
tua metafora, alla fine hai sempre un minestrone - ammesso che tu ti sia
espresso nei termini previsti. Se leggi la definizione p. es. del C++
scopri che in vari posti ci sono frasi del tipo: se il programma è espresso in questo modo o quell'altro il comportamento è:
- indefinito;
- definito dall'implementazione.

Un conto è dimmi la dimensione del file e il compilatore o chi per esso trova il sistema di farmela sapere.

Secondo te, cosa sarebbe "la" dimensione del file ?

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

Infatti se incapsuli il problema in una funzione, la chiami in un modo
che ne suggerisca gli intenti e la usi sei a posto. Hai anche modo di
scrivere qualche test della funzione stessa.

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.

In generale, non c'è modo di stabilire quale sia la dimensione del
file: in un sistema multiprocesso un altro processo può fare truncate()
mentre sto scrivendo e Unix non fa una piega, il risultato è uno sparse
file. Il seek offset è un offset che il kernel associa al file descriptor e usa soltanto quando riceve una read() o una write(), allo
stesso modo la position di uno stream C++ è un off_t che viene usata
solo al momento di << o >>, che peraltro lavorano in un buffer e vanno
su disco solo quando necessario.

Mi pare il caso di ribadire una distinzione importante: un sysadmin ha
a che fare con una o più macchine reali, dove i file sono file e le
directory sono directory; uno sviluppatore deve esprimere il programma
in termini di interfacce, contratti, promesse e requisiti, se
non vuole soffocare di debug.
La soluzione "ficca in una funzione" risponde sia a non è possibile astrarre sia a nessuno lo ha mai fatto.

No, chi ha scritto lo standard semplicemente si è già scontrato con
il problema per cui il concetto di dimensione del file non deve essere
utilizzato da uno sviluppatore: nasconde troppe cose che possono andare
storte. Offre quindi gli strumenti che consentono di arrivare a scrivere
codice funzionante, facendo riflettere se ciò che serve è proprio la
dimensione del file piuttosto che semplicemente essere sicuri di scrivere in fondo al file.

Davide Bolcioni
--
There is no place like /home.



<Prev in Thread] Current Thread [Next in Thread>