Newsgroup: it.comp.lang.c++
Titolo: richiamare il costruttore

ciao,
forse è una domanda senza senso, sono poco esperto di c++
è lecito/sensato chiamare da un metodo il costruttore della propria
classe?
nel caso specifico il costruttore NON alloca memoria ma si limita ad
inizializzare i campi;
la trovo più mantenibile come soluzione rispetto a fare un copia/
incolla del codice del costruttore
in genere si fa così?
class myClass {
int x,y,z;
public:
myClass();
void f1();
}
myClass::myClass{
x=1; y=2; z=3;
}
myClass::f1() {
myClass();
}
myClass matrix[5][7];
void main() {
matrix[1][3].f1();
}

 inizializzare i campi;
Allora prendi il codice di cleanup/inizializzazione, mettilo in un 
metodo Init() e chiamalo dal costruttore oltre che dagli altri metodi, 
se occorre.
Ciao
-- 
Morde

 se occorre.
ottimo suggerimento, non ci avevo pensato!
faccio così
ne approfitto per un'altra domanda:
se (come nell'esempio che ho scritto) il costruttore NON alloca
memoria è corretto dire che non serve dichiarare esplicitamente il
distruttore (e ci si affida a quello di default)?
grazie 1000
-ice-

 distruttore (e ci si affida a quello di default)?
Seguendo alla lettera il tuo esempio, si, ma da un punto di vista piï¿œ 
ampio di programmazione OOP no, non ï¿œ corretto dirlo, perchï¿œ il fatto 
che il "costruttore NON alloca memoria" non ï¿œ l'unico caso da 
considerare: la tua classe potrebbe allocare risorse in altri momenti 
della sua esistenza, magari all'interno di metodi richiamati dopo la 
sua costruzione.
ciao
-- 
Morde

 sua costruzione.
quando dici "allocare risorse" intendi l'uso esplicito di new(),
malloc() ecc?
un metodo che ha una struttura statica locale NON si considera
allocazione di memoria (spero)
cioè nel senso che se un metodo dichiara "int buffer[1000];" il
distruttore non deve disallocare nulla dato che il vettore è locale al
metodo?
-ice-

On 25/05/2010 16:56, ice wrote:
 > ciao,
Ciao.
Oltre a quanto ti hanno già detto, vorrei aggiungere due cose
 > è lecito/sensato chiamare da un metodo il costruttore della propria
 > classe?
Non è sensato e, soprattutto, non è possibile.
 > myClass::f1() {
 > myClass();
Quanto hai scritto non ha l'effetto che pensi.
Quello che succede in realtà è che all'interno della funzione f1 viene 
costruito un oggetto temporaneo senza nome di tipo myClass che viene 
distrutto all'uscita della funzione.
 > void main()
La funzione main *deve* restituire un int. La maggior parte dei 
compilatori accetta senza problemi anche una main void, ma ciò non 
toglie che sia un errore.
Ciao.

 metodo?
Si non devi disallocare nulla, ma non è perchè il vettore è locale al 
metodo, quanto perchè hai allocato memoria in modo statico, ed essa 
verrà liberata all'uscita dello scope in modo automatico.
Nel caso di allocazione dinamica, invece, il principio generale è che 
ad ogni allocazione, deve esserci la corrispondente deallocazione: ogni 
new avrà la sua delete.
Tu potresti fare una new nella fase di creazione di un tuo oggetto, 
usare e ampliare la memoria occupata da quella new durante il ciclo di 
vita dell'oggetto, e poi farai la free della memoria solo alla fine 
della vita dell'oggetto. E' questo che intendevo dirti.
Ciao
-- 
Morde

 della vita dell'oggetto. E' questo che intendevo dirti.
tutto chiaro, ti ringrazio!
(molto interessante questa OOP... mi ricorda vagamente il turbo vision
del pascal di anni fa)
-ice-


La utilizzavo pure io sia con il turbo pascal 6.0 che il turbo c++ 5.0,
in effetti la turbo vision era pensato come un framework ad oggetti,
quindi non è tanto il fatto che te la ricorda quando semplicemente che
tv era pensato ad oggetti.

 tv era pensato ad oggetti.
BTW, stavo leggendo la documentazione del framework delle QT, 
suggeritomi in altro thread, e vedo che è stata semplificata 
notevolmente la gestione della memoria, demandando alla classe padre, 
l'owner, le free dei figli.
http://www.digitalfanatics.org/projects/qt_tutorial/it/chapter02.html
mi ricorda molto la VCL di delphi, dove in alcuni componenti potevi 
decidere da codice se il padre era responsabile della free dei figli o 
meno.
Ciao
-- 
Morde

 sua costruzione.
Ma soprattutto... il distruttore di default non è virtual e potrebbe
quindi impedire l'esecuzione del distruttore delle classi derivate nel
caso si sfrutti il polimorfismo.
http://stackoverflow.com/questions/1117481/can-the-default-destructor-be-generated-as-a-virtual-destructor-automatically
Ciao
Mattia