Newsgroup: it.comp.lang.c++
Titolo: Safe deleting

Salve a tutti,
	Vorrei implementare una funzione di delete per un generico puntatore,
che controlli sia allocato prima di cancellarlo, forzandolo a NULL.
Ho scritto:
template <class T>
bool safeDelete(T* pointer)
{
~  if(pointer == NULL)
~  	return false;
// L'operatore delete dovrebbe lasciare a NULL il puntatore liberato da
// solo, ma non guasta arrangiarsi:
~  T* tmp= pointer;
~  pointer= NULL;
~  delete tmp;
~  return true;
}
ricevendo pero':
free(): invalid pointer 0x804ca98!
Segmentation fault
Qualsiasi aiuto/consiglio e' graditissimo!
sakurai.

 Segmentation fault
questo non so... ti sei accertato di aver allocato con new e rilasciato 
con delete?
-- 
"Siamo una generazione di uomini cresciuti dalle donne, mi chiedo se 
un'altra donna č veramente la risposta che ci serve"


Ciao,
a meno che non sia un esercizio didattico e nel caso tu non lo sappia, puoi
utilizzare gli smart pointers che non hanno bisogno di delete, perchè sono
automaticamente deallocati.
Maurus

 
Hai ragione!
scrivendo invece:
template <class T>
bool safeDelete(T*& pointer)
L'assegnamento e' valido anche al di fuori della funzione, giusto?
Si... e' un esercizio didattico...
Grazie mille!
sakurai.

 L'assegnamento e' valido anche al di fuori della funzione, giusto?
giusto!
-- 
"Siamo una generazione di uomini cresciuti dalle donne, mi chiedo se 
un'altra donna è veramente la risposta che ci serve"

 Si... e' un esercizio didattico...
Cosi' funziona. L'importante pero' e' che tu abbia chiaro che la tua
safeDelete non solo non serve a niente, ma e' anche nociva. Poni di
avere
int * p = new int(6);
int * q = p;
safeDelete(p);
E q?
Ciao,
Nicola

 E q?
con questa logica risultano inutili pure gli std::auto_ptr e tutti gli 
smart-pointer della libreria boost, ne convieni?
-- 
"Siamo una generazione di uomini cresciuti dalle donne, mi chiedo se 
un'altra donna è veramente la risposta che ci serve"

 smart-pointer della libreria boost, ne convieni?
Ma il discordo di evitare i puntatori in C++ non è legato anche alle
eccezioni ? Se nella stessa funzione allochi ed in tutti i return
deallochi, forse una qualsiasi funzione che tu chiami potrebbe lanciare
un eccezione e ti ritrovi con le cose non deallocate.
Saluti
-- 
alef

alef wrote:

sono d'accordo con te, ma quì il discorso mi pareva diverso... anche gli 
auto_ptr (ad esempio) hanno il problema che evidenziava Nicola, in un 
modo o nell'altro: ovvero se il puntatore a cui lo smart pointer fa da 
wrapper viene mantenuto in giro per il codice l'efficacia dello smart 
pointer stesso viene a cadere.


 pointer stesso viene a cadere.
Ho capito il problema; come fare allora a vedere se una certa zona di
memoria e' gia' stata deallocata? ... oppure devo usare solo referenze a
puntatori (cosi' vado sul sicuro, ma mi sembra laborioso)?
Rinunciare ai puntatori, beh, tanto vale usare il java, no? =)
sakurai.

 Rinunciare ai puntatori, beh, tanto vale usare il java, no? =)
perchè no? il mio motto è "ad ogni progetto il suo ldp" :-)


 smart-pointer della libreria boost, ne convieni?
Ti sbagli. Gli smart pointer sono fatti per gestire *tutti* i
puntatori ad un singolo oggetto, o rendendo difficoltosa l'esistenza
di piu' di un puntatore o tenendo traccia di tutti i puntatori ad uno
stesso oggetto. L'oggetto non viene cancellato finche' esiste un
puntatore valido ad esso e viene comunque cancellato dal distruttore
dell'ultimo smart pointer che lo punta.
In questo modo non hai mai puntatori non validi, a meno che tu non lo
faccia apposta.
Ciao,
Nicola

 faccia apposta.
Sono d'accordo con quello che dici, ma mi sembra che basti fare 
semplicemente questo per mandare all'aria tutto il castello che ti 
costruisci con gli smart-pointer:
int * a = new int(16);
std::auto_ptr b(a);
delete a;
e non è nemmeno necessario farlo apposta, basta una semplice svista..


 un eccezione e ti ritrovi con le cose non deallocate.
Questo aspetto non c'entra molto con la discussione originale, no?
Certamente uno degli scopi degli smart pointer e' garantire la
cancellazione dei puntatori in presenza di eccezioni.
Ciao,
Nicola

 pointer stesso viene a cadere.
La differenza pero' e' che questa e' una violazione del "contratto"
garantito da auto_ptr. Se fai delle librerie un uso sbagliato sono
affari tuoi. Coi puntatori semplici invece non esistono meccanismi di
controllo a priori.
Ciao,
Nicola

 puntatori (cosi' vado sul sicuro, ma mi sembra laborioso)?
Questo non te lo consente nessun linguaggio. Tutt'al piu' ti possono
mettere in condizione di non avere bisogno di saperlo, tramite
meccanismi come gli smart pointer o la garbage collection.
L'uso di reference ai puntatori non e' di alcun aiuto, perche' resta
il problema di poter avere piu' puntatori alla stessa area di memoria.
Ciao,
Nicola

 perchè no? il mio motto è "ad ogni progetto il suo ldp" :-)
Perche' a meno che tu non possa utilizzare una libreria che fa gia'
*molto* del lavoro e della quale non esiste un analogo in C++, l'uso
di Java ha piu' svantaggi che vantaggi.
Ciao,
Nicola

Nicola Musatti wrote:

beh, il commento voleva essere scherzoso perchè non ho nessuna voglia di 
fare un confronto C++ - Java in un NG (non voglio guerre religiose sulla 
coscienza). Di sicuro non scarto nulla a priori, e se Java si adatta 
molto meglio alla situazione non mi farei problemi ad utilizzarlo. Per 
il resto, non mi pronuncio :-)


Nicola Musatti wrote:

ma il "contratto" è comunque qualcosa che stabilisci via documentazione, 
non la puoi *forzare* via codice (vedi esempio che ho scritto). A questo 
punto, si possono stabilire contratti anche per i raw pointer e 
probabilmente non ci sarebbero problemi, se tutti li rispettassero. 
Tutto questo non per dire che i raw-pointer abbiano la stessa 
difficolta' d'utilizzo degli smart-pointer, ma più che altro che anche 
l'utilizzo degli smart-pointer richiede un minimo d'attenzione da parte 
del programmatore (ad esempio, imho è veramente facile scottarsi con gli 
auto_ptr).


 auto_ptr).
Su questo non c'e' dubbio.
Ciao,
Nicola

 e non è nemmeno necessario farlo apposta, basta una semplice svista..
Chi spara per terra si merita i buchi nei piedi.
Ciao,
Nicola