51 risposte a questa discussione

[toyo]

leggo in giro che

Qt maintains hierarchies of objects. For widgets (visible elements) these hierarchies represent the stacking order of the widgets themselves, for non-widgets they merely express "ownership" of objects. Qt deletes child objects together with their parent object. While this takes care of 90% of memory handling problems it also brings some challenges and leaves a few aspects open.

quindi per esempio, se istanzio un QWidget o QDialog, nel momento in cui vado a fare la delete di questi, viene automagicamente chiamata anche la delete della roba istanziata nello heap dentro al QWidget / QDialog?

Sul serio?

[toyo]

quante ferie fa trallallero?

[Killer application]

passa al java.

Noi abbiamo il garbage collector.


e i cookies.

[toyo]

Ok chiedo su HTML.it, cancellate pure il topic

Mio ultimo post d'ora in poi lurkeró e basta

cit.

[MadJackal]

Le QT non sono magiche, eh.
Si occupano della loro memoria, non della tua.

Se è un problema, passa a Java.

[toyo]

Le QT non sono magiche, eh.
Si occupano della loro memoria, non della tua.

Se è un problema, passa a Java.

il prossimo progetto, il più grosso della laurea, è (molto probabilmente) in java. Intanto smettila


Per tralla:

esempio:
ho una classe

class IscrDialog: public QDialog

nel costruttore ho tipo dei

QVBoxLayout* v1= new QVBoxLayout(this);

    QFormLayout* f1= new QFormLayout();

poi anche altre cose, ma intanto volevo capire questo:

vengono deallocati v1 e f1 quando chiudo la finestra? sì tutti e 2/solo v1 perchè come padre gli passo this/nessuno dei due e devo ricordarmi di distruggerli nel distruttore?



Cioè in pratica devo capire meglio questo

Qt maintains hierarchies of objects. For widgets (visible elements) these hierarchies represent the stacking order of the widgets themselves, for non-widgets they merely express "ownership" of objects. Qt deletes child objects together with their parent object. While this takes care of 90% of memory handling problems it also brings some challenges and leaves a few aspects open.

grazie

[trallallero]

Se ovunque, nel programma qt, fai una new di oggetti tuoi senza dargli come parent un oggetto di qt, poi sta a te eliminarlo.
Se crei un oggetto qt e nel costruttore gli passi this come parent, ci pensa qt poi ad deletarlo.

Comunque per tutto il resto boost share pointers wtf

[trallallero]

Ah, dimenticavo, il java lascialo ai ritardati

(giusto per dare un po di audience al thread)

[toyo]

Se ovunque, nel programma qt, fai una new di oggetti tuoi senza dargli come parent un oggetto di qt, poi sta a te eliminarlo.
Se crei un oggetto qt e nel costruttore gli passi this come parent, ci pensa qt poi ad deletarlo.

Comunque per tutto il resto boost share pointers wtf

si ok però nell'esempio che ti ho messo, con i Q*Layout, non posso dare this a f1, mi dà errore in quanto mi dice che esiste già un layout per questo widget.
quindi in questo caso è "obbligatorio" che metta la delete nel distruttore giusto?

Also, il distruttore viene invocato quando c'è l'evento exit?

[trallallero]

@[/url]":1c07kbw1] Se ovunque, nel programma qt, fai una new di oggetti tuoi senza dargli come parent un oggetto di qt, poi sta a te eliminarlo.
Se crei un oggetto qt e nel costruttore gli passi this come parent, ci pensa qt poi ad deletarlo.

Comunque per tutto il resto boost share pointers wtf

si ok però nell'esempio che ti ho messo, con i Q*Layout, non posso dare this a f1, mi dà errore in quanto mi dice che esiste già un layout per questo widget.
quindi in questo caso è "obbligatorio" che metta la delete nel distruttore giusto?

Si. Come scritto nella documentazione, qt ha bisogno di conoscere la gerarchia degli oggetti per poter poi deletare tutto nel modo giusto. Se crei un oggetto ma non dici a qt di chi è figlio, lo devi cancellare da solo.

Also, il distruttore viene invocato quando c'è l'evento exit?

Direi di si. Ma per essere sicuro dovresti controllare la gestione eventi/signals di qt.
Sai come funziona no ? signal/connect/event e via dicendo...

[trallallero]

Ma perché dovresti chiamare exit() ? solo in caso di errore immagino.

[toyo]

Si. Come scritto nella documentazione, qt ha bisogno di conoscere la gerarchia degli oggetti per poter poi deletare tutto nel modo giusto. Se crei un oggetto ma non dici a qt di chi è figlio, lo devi cancellare da solo.

ah ok. Quindi devo stare attento a tutti i layout "annidati". Oppure fare un widget per ogni layout ma sarebbe un po' uno scazzo, avrei over 9000 classi.

Direi di si. Ma per essere sicuro dovresti controllare la gestione eventi/signals di qt.
Sai come funziona no ? signal/connect/event e via dicendo...

, molto figa

Grazie intanto

[toyo]

Ma perché dovresti chiamare exit() ? solo in caso di errore immagino.

non viene chiamato exit() quando chiudo la finestra? L'ho anche ridefinito e funziona, spe che controllo.

[toyo]

ah no sono scemo, intendevo CloseEvent(), difatti ho cosato così

void LegamiGui::closeEvent(QCloseEvent *event)

 {

    db->salva();

    event->accept();





 }

eh ho fatto un po' di ferie in mezzo al progetto

[trallallero]

Ovviamente do per scontato che tu intenda QApplication::exit(0) e non la funzione C exit() (se poi qt abbia dei signal catcher e chiami i distruttori anche in quel caso non so, ma è più pulito ed elegante uscire chiamando la funzione di QT).

Per il resto, come t'ho detto prima, puoi usare boost::shared_ptr.
Copincollo parte del mio codice:

boost::shared_ptr m_Jrtp; // dichiarazione

m_Jrtp.reset(new RTPWrapper::RTP_WrapperJrtplib(...); // alloca pointer

m_Jrtp->... // uso del pointer

m_Jrtp.reset(); // delete pointer ma non serve perché fatto in automatico da boost

Praticamente funziona come un garbage collector solo che non è per ritardati

[trallallero]

toyo, non voglio sapere cosa ci fai con una Legami Gui

[toyo]

eh ho scritto sopra che mi ero confuso con QCloseEvent scusa.

i boost cosi sono degli smart pointers già pronti giusto?

Perché avrei anche i miei già pronti in giro.

[trallallero]

boost è tutto un insieme di librerie C++ open, molto facile da usare e molto efficiente.
Va dalle normali string all'asio passando per threads a mutex.
Solo NON guardare il codice di boost perché se lo fai ti senti scemo.