[C++][Qt]2 manieren van initialiseren van een object

[Compizfox]

Hallo Devschuurders,

Ik ben aan het coden in Qt en liep tegen iets aan dat ik niet kan verklaren. Ik heb nog niet heel veel ervaring met C++ en Qt en ik hoop dat jullie dit kunnen ophelderen

Ik wil een item aan een QTreeWidget toevoegen. Mijn eerste idee was om dat op de volgende manier te doen:

C++:

QTreeWidgetItem item(ui->treeWidget);
item.setText(0, expression);
item.setText(1, QString::number(ans));
ui->treeWidget->addTopLevelItem(&item);

Na wat research blijkt de correcte manier er niet veel van te verschillen:

C++:

QTreeWidgetItem * item = new QTreeWidgetItem(ui->treeWidget);
item->setText(0, expression);
item->setText(1, QString::number(ans));
ui->treeWidget->addTopLevelItem(item);

Die eerste code werkt niet (er verschijnt geen item in de treewidget). De tweede wel.
Maar ik snap niet wat het verschil is tussen de twee. In de eerste code maak ik een object genaamd item van het type QTreeWidgetItem. Die geef ik een tekst en ik pass een pointer naar dat item naar addTopLevelItem.
In het tweede geval maak ik een pointer naar QTreeWidgetItem die ik initialiseer mbv new en daarna ook pass naar addTopLevelItem. Ik zou zeggen dat deze manier omslachtiger is en ik snap dan ook niet waarom dit blijkbaar wel zo moet.

Alvast bedankt voor de uitleg!

[CoolGamer]

In de eerste variant wordt het object verwijderd uit het geheugen zodra het einde van de functie wordt bereikt, terwijl de tweede variant pas wordt verwijderd zodra je delete item aanroept. Het geheugen in de eerste variant kan dus weer overschreven worden zodra de functie is afgelopen, wat kan lijden tot crashes of onverwachts gedrag.

Zodra je een object meegeeft als pointer zal je erop moeten letten dat het object nog bestaat zodra de functie er wat mee gaat doen, iets wat dus in de eerste variant niet gebeurd. In de tweede variant gebeurd dat wel.

[Sebazzz]

Het eerste voorbeeld maakt de QTreeWidgetItem op de stack, en die verdwijnt bij het verlaten van de functie. Bij de tweede maak je het op de heap aan. Objecten op de heap bestaan totdat ze door jou of andere code verwijderd worden.

Correct me if I'm wrong

[Compizfox]

Ah, ik snap het, thanks! Daar had ik totaal niet aan gedacht. Als ik het oject gedeclareerd had als

C++:

static QTreeWidgetItem item(ui->treeWidget);

zou het dus ook moeten werken?

[BoAC]

Zou je dan al je items als static willen maken? Dat moet je niet willen.
Maak ze member van je klasse in bijvoorbeeld een list.

@Sebazzz: Correct.

[ Voor 22% gewijzigd door BoAC op 11-09-2012 08:54 ]

[epic007]

Hier wat info over hoe Qt met objecten omgaat: http://doc.qt.nokia.com/4.7-snapshot/objecttrees.html

Qt objecten zorgen zelf voor het opruimen van child objecten. Een soort ingebouwde garbage collection dus.

[.oisyn]

Compizfox schreef op maandag 10 september 2012 @ 23:18:
Ah, ik snap het, thanks! Daar had ik totaal niet aan gedacht. Als ik het oject gedeclareerd had als

C++:

static QTreeWidgetItem item(ui->treeWidget);

zou het dus ook moeten werken?

Ligt eraan of je de functie meerdere keren aanroept, want er wordt op die manier altijd maar 1 item voor de gehele looptijd (althans, vanaf de eerste aanroep van de functie) van het programma gemaakt, die dan vervolgens wel per functieaanroep wordt toegevoegd.

[Zoijar]

Je mag toch geen pointer naar statics in een functie buiten die functie gebruiken? Of vergis ik me?

[.oisyn]

Why on earth not? Dan zou Stroustrup's singleton idiom ook niet mogen

C++:

SomeType & GetInstance()
{
    static SomeType instance;
    return instance;
}

[farlane]

Compizfox schreef op maandag 10 september 2012 @ 23:18:
Ah, ik snap het, thanks! Daar had ik totaal niet aan gedacht. Als ik het oject gedeclareerd had als

C++:

static QTreeWidgetItem item(ui->treeWidget);

zou het dus ook moeten werken?

Je hebt dan in je hele applicatie maar 1 QTreeWidgetItem item, veranderingen aan dit object zullen dan ook te zien zijn in alle items in je tree ( als je hem meerdere keren toevoegt ).

Zoijar schreef op dinsdag 11 september 2012 @ 11:14:
Je mag toch geen pointer naar statics in een functie buiten die functie gebruiken? Of vergis ik me?

Die staan ook in de static store dus dat is weldegelijk toegestaan.

[Zoijar]

.oisyn schreef op dinsdag 11 september 2012 @ 11:34:
Why on earth not? Dan zou Soustrup's singleton idiom ook niet mogen

C++:

SomeType & GetInstance()
{
    static SomeType instance;
    return instance;
}

Duidelijk

[MSalters]

Evengoed mag de static niet met Qt. Qt gaat namelijk

delete

aanroepen op je object, en dat mag alleen als het object met

new

is aangemaakt.

[BoAC]

MSalters schreef op dinsdag 11 september 2012 @ 13:16:
Evengoed mag de static niet met Qt. Qt gaat namelijk

delete

aanroepen op je object, en dat mag alleen als het object met

new

is aangemaakt.

Even correctie hierop. Static staat hier namelijk los van (je kunt ook een static pointer hebben )
Je bedoeld dat Qt objecten altijd moeten gealloceerd worden met de new operator.

[Compizfox]

farlane schreef op dinsdag 11 september 2012 @ 12:02:
[...]
Je hebt dan in je hele applicatie maar 1 QTreeWidgetItem item, veranderingen aan dit object zullen dan ook te zien zijn in alle items in je tree ( als je hem meerdere keren toevoegt ).

Duidelijk. De functie wordt inderdaad meerdere keren aangeroepen dus dat zal dan niet werken.

[Zoijar]

BoAC schreef op dinsdag 11 september 2012 @ 13:35:
Je bedoeld dat Qt objecten altijd moeten gealloceerd worden met de new operator.

Dat is dan ook weer niet waar Je mag prima een QObject op de stack zetten, en die wordt dan netjes door de dtor opgeruimd.

Je krijgt pas problemen als zo'n stack object een child is van een ander object. En, zoals boven uitgelegd, dan alleen als de parent als eerst wordt gewist. De dtor van een child ontkoppelt een child namelijk van zijn parent, dus als eerst de dtor van het child draait en dan de parent is er niks aan de hand.

Maar het is iha aan te raden QObjects op de heap aan te maken.

[BoAC]

Zoijar schreef op dinsdag 11 september 2012 @ 16:14:
[...]

..

Maar het is iha(=in het algemeen) aan te raden QObjects op de heap aan te maken.

You're right.. want het vinden van het probleem veroorzaakt door deze fout is zeer lastig als je nog slecht bekend bent met C++ en dtor's zoals de TS