Newsgroup: it.comp.lang.c++
Titolo: Garbage collector per C++

Leggendo C++ Informer #12 di Carlo Pescio e soprattutto il libro
di Stroustrup "C++ linguaggio, libreria standard e principi di
programmazione"
ho realizzato che cominciano a prendere piede con ottimi risultati anche per
il C++
dei garbage collector (spesso conservativi, p.e.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
).
Spesso queste librerie possono essere utilizzate in fase di test come leak
detector, per controllare
oggetti allocati ma che sono usciti dallo scope e non sono più accessibili.
Questo apre la possibilità, secondo me, ad una semplificazione molto
sensibile del lavoro di un programmatore

ehm dicevo.....

sensibile del lavoro un programmatore anche alla luce del fatto che dagli
studi sembra prestazionalmente molto valido (almeno l'approccio
conservativo).
Volevo appunto sapere da voi cosa ne pensate di questo sviluppo, se state
utilizzando
qualche implementazione (e quale) o se pensate di utilizzarla (o almeno
testarla) in
futuro.
Lello

Non mi sono ancora posto seriamente il problema, anche perche' tendo a
concentrare la gestione della memoria nei contenitori standard e in
puntatori intelligenti.
Un argomento in qualche modo collegato sono le implementazioni "safe"
della standard library. Credo che la prima implementazione (SafeSTL) sia
di Cay Horstmann, ma il meccanismo e' disponibile anche in STLport
(
www.stlport.org
)
Ciao,
Nicola

 ha scritto nel messaggio
news:3A62FB0D...@divalsim.it...


STL multipiattaforma, "safe" rispetto alle eccezioni e ai thread.
Giusto ieri (non sto scherzando) ho sbattuto violentemente il muso
contro std::map e multithreading in VC++. Ora sono presissimo ma
appena ho un po' di tempo un giro sulle pagine di questa
implementazione lo faccio :)
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

utilizzando
Io non sono mai stato un tifoso dei GC ... in un programma non ho mai
trovato tutta questa complicazione nel gestire le deallocazioni di
quanto si alloca.
Pero' una volta ero anche un sostenitore del fatto che chi facesse
la free dovesse sapere quanto era grande il blocco di memoria (come in
pascal). Il mio ragionamento era semplice: chi dealloca qualcosa
dovrebbe sapere cosa sta facendo (essere cioe' il "distruttore" del
caso) e sapere la dimensione dei dati mi pareva fosse il minimo visto
che spesso dovra' fare anche altre operazioni di dismissione della
struttura dinamica che sta deallocando.
Con il tempo pero' mi sono abituato alla free e non so se mi
piacerebbe tornare indietro :) ... forse un giorno mi abituero' anche
all'idea che gli oggetti basta "dimenticarseli" per vederli sparire.
Per ora la trovo una idea assurda e tremo al pensiero di questa
ulteriore variabile runtime (il momento e l'ordine di distruzione
vera e propria che viene deciso liberamente dal sistema a seconda
delle fasi lunari e della temperatura ambiente).
Ho anche una brutta esperienza con Java, dove questo mitico GC e'
presente fin dalla definizione del linguaggio. Dopo aver visto
applet che se messi in una pagina HTML mangiano e fanno sparire
per sempre blocchi da megabyte e che fanno in modo che usando solo
la pressione del tasto di "reload" del browser si riesca a mettere
un sistema in ginocchio non mi fido piu' molto delle dichiarazioni
di intento dei GC.
Mah... vedremo come va a finire anche questa cosa...


STL multipiattaforma, "safe" rispetto alle eccezioni e ai thread.
Almeno limitatamente ai contenitori (con solo 2 eccezioni) la libreria standard
del C++ e` gia` exception safe e in particolare implementa una politica
commit or rollback
Paolo
--
Paolo Marotta
Duck Communication Entertainment s.r.l.
Largo Arenula, 11 - Roma
http://www.duckce.com
p.ma...@duckce.com
-- 
Posted from 
HA-server-a.cs.interbusiness.it
 [151.99.250.31] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
).
[...]
Proprio leggendo la newsletter di Pescio mi sono reso conto che una
delle caratteristiche fondamentali del C++ e' la garanzia deterministica
della chiamata al distruttore di ogni oggetto istanziato. Trovo
l'esempio sull'aggiunta del blocco finally al try/catch estremamente
calzante e, da solo, dimostrazione della superiorita' concettuale del
C++.
Per questo motivo penso che la mancata chiamata di "delete" *al momento
opportuno* costituisca in genere un baco non risolvibile tramite Garbage
Collection. Per questo mi sembra che i GC possano essere un buon
supporto al debugging, ma in generale non baserei su questo tipo di
meccanismi l'architettura vera e propria di un'applicazione, se non in
contesti molto specifici.
Ciao,
Nicola

pascal).
Aspetta, puo' darsi che abbia intuito male cosa vuoi dire.
Quando parli di "chi" fa la free, intendi il programmatore o il
sistema ?
Il sistema, chiaramente, conosce sempre la dimensione del blocco
allocato e il programmatore non ne ha bisogno, a mio avviso.
In Pascal non c'e' alcuna specificazione della dimensione della
quantita' di memoria da deallocare.
Mi riferisco sia a New/Dispose che a GetMem/FreeMem di TP/Delphi.
(In realta' con questi ultimi, la specificazione della dimensione e'
opzionale).
--
Andrea Laforgia (ICQ 87230455)
http://www.geocities.com/AndreaLaforgia
"ci sono tre tipi di persone nel mondo : quelli che
 sono bravi in matematica e quelli che non lo sono."

quantita' di memoria da deallocare.
c'era con le vecchie versioni del turbo pascal
Io la ritenevo una cosa tutto sommato sensata... un programma
con una parte di codice che liberasse della memoria senza
sapere esattamente quanta mi sembrava un assurdo (dal punto
di vista filosofico). La deallocazione di una struttura dati
io ho sempre cercato di tenerla in un posto solo (che potremmo
definire "il distruttore") e chi ha questo incarico aveva
secondo me anche il dovere morale di conoscere esattamente la
quantita' di memoria che era stata allocata (oltre a sapere
cosa altro era necessario fare... come ad es. chiudere un
file associato alla struttura dati che si stava distruggendo).
Poi ho iniziato a lavorare object-oriented in C ed e' cominciato
a venire comodo il poter dire "free" senza conoscere esattamente
la dimensione (in particolare per il distruttore di una
classe da cui erano state derivate altre classi).


di vista filosofico).
E' troppo difficile per me da capire.
Il meccanismo di allocazione/deallocazione della memoria e' qualcosa
di "interno" al sistema. La quantita' di memoria allocata viene
*comunque* memorizzata con l'allocazione, sicche' la deallocazione
puo' conoscere tranquillamente *quanto* deallocare.
Non vedo perche' lasciare questo onere al programmatore, visto che lo
stesso potrebbe tentare di deallocare una quantita' di memoria
superiore o inferiore a quella necessaria (creando, quindi, possibili
bug).


 versione del TP ?
E non c'era neanche nel Pascal originale di Wirth.
EMG

bug).
Si potrebbe vedere anche al contrario... obbligare il chiamante
a specificare la dimensione potrebbe aiutare a "evitare" errori
di logica nei programmi (sarebbe una specie di assert... con
"evitare" intendo scoprire e correggere).
Se un programma libera un blocco che secondo il programmatore
dovrebbe essere di 20 byte e invece e' di 10 l'errore di logica
c'e' comunque ...
Io pero' non sto dicendo che la free dovrebbe ricevere anche la
dimensione del blocco... ho detto pero' che c'e' stato un
periodo in cui credevo che fosse la cosa piu' giusta.
Oggi ritengo che una free "comoda" dovrebbe (come fanno quelle
di C/C++) scaricare il programmatore da questo onere visto che
il costo addizionale e' comunque abbastanza basso.
Tornando al merito della discussione io *oggi* non ritengo che
i GC siano interessanti in C++ e secondo me un programmatore
dovrebbe farsi carico di quando le cose nascono e quando
muoiono esplicitamente... (al limite usando dei reference
counter quando si ritiene utile).
Forse un domani mi ammorbidiro' anche su questo (pero' prima
dovrei perlomeno vedere dei GC che funzionano davvero); per
ora resto un forte sostenitore dei reference counter (ho
scritto diversi interpreti in cui la gestione memoria e'
"automatica", ma sempre basati su reference counting e non
su garbage collector).
Diciamo che preferisco usare i cestini invece di gettare le
cartacce dal finestrino della macchina contando che comunque
c'e' qualcuno pagato per raccoglierle :DDDD
Andrea


E non c'era neanche nel Pascal originale di Wirth.
Non ho mai lavorato con il pascal "puro" e devo dire che mi
stupisce che fossero presenti funzioni come GetMem e FreeMem
"new" e "dispose" sono ovviamente un discorso completamente
diverso: in questo caso il compilatore conosce la dimensione
dell'oggetto allocato.
Andrea


 stupisce che fossero presenti funzioni come GetMem e FreeMem
Infatti non mi pare ci fossero. Intendevo dire che non c'era nessun
meccanismo per specificare esplicitamente la quantità di memoria da
rilasciare.
EMG

rilasciare.
hehehe... vero... ma non c'era neanche modo di specificare
esplicitamente quanta memoria richiedere :D
Nel turbo pascal erano state introdotte una serie di
estensioni che rendevano il linguaggio simile (come potenza)
al C... ad esempio il casting di puntatori (esplicito oppure
grazie alle variabili dichiarate "absolute") getmem(=malloc)
e freemem(=free).
La differenza di cui si stava discutendo e' che freemem
richiedeva che il programmatore passasse anche la dimensione
del blocco che doveva coincidere con quanto era stato chiesto
in origine a getmem (diversamente da quello che accade in
C/C++ dove la dimensione richiesta con malloc/operator new
se la ricorda la libreria e non deve essere passata a
free/operator delete).


stupisce che fossero presenti funzioni come GetMem e FreeMem
Difatti non c'erano.
Ho citato "GetMem/FreeMem di TP/Delphi".
Sono una particolarita' Borland.


c'e' comunque ...
Mah... secondo me, in questi casi, l'errore e' del programmatore.
Scusami, ma non riesco ad immaginare casi in cui e' il sistema a
"sbagliare". Se il blocco dovrebbe essere di 20 byte, ma in realta' ce
ne sono solo 10, e' il programmatore che ha fatto lo sbaglio di
allocarne solo 10 e sta tentando di deallocarne 20, quindi l'errore e'
il suo.


il suo.
Assolutamente... e sarebbe importante fermare tutto subito
per evidenziare il problema. Con free() il programmatore deve
fornire al gestore memoria meno informazioni e quindi quest'ultimo
deve *presumere* che il programmatore sappia cosa sta facendo.
Non ti e' mai capitato un modulo in cui devi compilare ad
esempio sia il numero di matricola che l'unita' di appartenenza
oppure il nome e cognome ? Ovviamente si tratta di informazioni
ridondanti (nota la matricola il nome e cognome sono disponibili
con un semplice lookup di database) ma appunto per questo si
tratta di informazioni che facilitano la scoperta di eventuali
errori. La ridondanza non e' sempre un peso.
Questo ovviamente in teoria: a me e' capitato di compilare un
modulo di versamento in cassa continua con numero di conto,
cognome, nome, indirizzo, altezza, peso, colore dei capelli,
nome da nubile di mia madre, impronta digitale e allegando un
pezzettino della retina del mio occhio sinistro ... e
nonostante questo vedere l'assegno finire nelle tasche di
un'altra persona perche' il numero di conto non era stato
scritto (secondo loro) in bella calligrafia.
Tu dici che tutti gli altri dati combaciavano ?


logico.
Sai che hai ragione ?
Ci ho ripensato ieri sera mentre leggevo "Essential COM" in bagno (non
sto scherzando, mi aiuta molto :)).
Chissa' quale strano meccanismo interno mi ha portato a pensare al
nostro problema e devo ammettere che e' una cosa plausibile ed
auspicabile che chi libera la memoria allocata sapere quanto e'
grande, al fine proprio di verificare se stia facendo o meno errori.
Strano a dirsi, ma avevo pensato proprio all'eventuale uso di una
"assert".
Mi hai convinto ! :)
