Newsgroup: it.comp.lang.c++
Titolo: Re: new/delete

 Mi sfugge qualche stupida cosa. Grazie a tutti,
Mentre aspetto cerco di spiegarmi meglio. Il programma termina normalmente
producendo:
main: a = 2 0x9a01008
main: a = 4 0x9a01008
invece io mi aspettavo un bel segfault alla riga "*a = 4;".
Fatemi sapere, please.
FabioMDF
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


Perche' usare memoria che ha subito delete e' un "undefined behaviour". 
Il che vuol dire che potrebbe segfaultare, potrebbe funzionare, potrebbe 
far esplodere il tuo computer, potrebbe portare la pace nel mondo o 
metterti in contatto con extraterrestri :)
Se vuoi sapere il motivo pratico... beh, e' dovuto a come vengono 
implementate new e delete. Ma stasera sono stanco, lascio ad altri 
questa eventuale spiegazione ;)
-- 
Mat/tia Belletti - Undergraduate student @ 
cs.unibo.it
ICQ: 33292311    - email: 
mbel...@cs.unibo.it
IRC: RedGlow     - site(s): 
http://mbellett.web.cs.unibo.it/
Jabber: RedGlow  - Linux registered user 299762 @ machine 213003

 ha
scritto:

Grazie. A questo punto faccio presente a Nick che questa risposta vale anche
per il suo problema sugli zeri stampati nel suo programma di gestione degli
alberi binari.


 nuovo standard (ricordo un articolo su cuj).
Interessante, a parte la FAQ di Stroustroup non ho letto nulla a
riguardo.
Hai mica un link?
 bye & Thanks
	av.

 Ciao, Enrico
Grazie. Vedi, normalmente io metto sempre a NULL il valore di un puntatore
dopo la delete come tu stesso consigli. Però il mio intendimento è sempre
stato solo quello di poter testare successivamente la presenza di un oggetto
con "if(a) then do" (pseudocodice) evitando così di fare la più pericolosa
"if(*a) then do". Ovviamente si capisce che il primo if ha senso solo se il
puntatore è stato messo a NULL perchè altrimenti "a" avrebbe comunque
l'indirizzo di locazione non più referenziabile; mentre essere obbligati al
secondo if avrebbe conseguenze disastrose se quell'area è già stata
allocata dal kernel ad un altro processo.
Sarebbe molto meglio che l'area appena rilasciata con "delete" venisse tolta
dallo spazio di memoria indirizzabile dal programma, cioè in modo
sincronizzato con la "delete". Capisco anche che questo è un compito da
assegnarsi al kernel tramite una syscall ipotetica inclusa dal compilatore
all'interno di "delete" e che utillizzata in modo sincronizzato non farebbe
ritornare la stessa "delete" se non dopo la effettiva deallocazione della
mamoria dallo spazio indirizzabile. Essendo questa una ipotetica syscall del
S.O. finchè non sarà creata e standardizzata è anche impossibile chiedere
al gruppo di lavoro sullo standard del C++ di prendere in considerazione di
modificare il comportamento di "delete", appunto rendendolo sincrono con la
deallocazione effettiva.
Saluti,


 ha scritto nel messaggio
news:416FBBEC...@netfence.it...
Interessante, a parte la FAQ di Stroustroup non ho letto nulla a
riguardo.
Hai mica un link?
Putroppo ho guardato sul sito di cuj e l'archivio č poco aggiornato. Posso
ritrovare l'articolo, forse.
Comunque era riguardo ad auto_ptr, se cerchi con google trovi molto.
Ciao, Enrico


Grazie e ciao,


 a NULL non aiuta.
Infatti il discorso era diverso o almeno cosí l'ho inteso. Fai un delete e
poi vai a riutilizzare il puntatore. Per me è buona norma dopo il delete
assegnare il puntatore a NULL cosí non vai a riutilizzarlo. Chiaro che ci
sono situazioni dove non è necessario.
Se hai più puntatori al medesimo oggetto sta a te essere disciplinato.
Ciao, Enrico

 disciplinato.
E` proprio in questo caso che e` piu` difficile essere disciplinati e
potrebbe fare comodo un controllo automatico e magari un core dump al
primo accesso sbagliato.
ciao,
        Mauro