QString, QStringList, QVariant etc am Heap /Stack anlegen?

[nullxff]

Hallo Leute!

Dass man die oben angeführten komplexen Datentypen auf dem Stack bzw. Heap anlegen kann, habe ich schon nachgelesen.
Allerdings ist es mir nicht ganz schlüssig, wie die unterschiedlichen Varianten zu verwenden sind...

Am Stack funktioniert dieser Code:

Code: Alles auswählen

    QStringList abc = QStringList() << "123" << " abc"
           << " def" << " 456";

Am Heap hätte ich die QStringList wie folgt angelegt:

Code: Alles auswählen

    QStringList *abc = new QStringList();

abc << << "123" << " abc"
           << " def" << " 456";

Was mir allerdings nicht klar ist, warum der Verschiebungsoperator bei der obigen Notation funktioniert, unten jedoch nicht?
Wenn mir jemand aus der Docu bzw. anhand den Header Files erklären könnte, wie man die richtige Syntax anwendet, wär mir sehr geholfen.

Das selbe gilt für QList<QVariant> bzw. QList<QVariant*>... Wäre toll wenn ich die Verwendung über die Header / Docu herausfinden könnte, und nicht jedes mal googeln müsste.

Vielen Dank

[Christian81]

Weil der Operator für das Objekt, nicht für den Pointer auf das Objekt definiert ist

Code: Alles auswählen

*abc << "blub";

[hilefoks]

Vielleicht noch eine Anmerkung von mir dazu.
Es ist natürlich möglich diese Typen auf dem Heap zu erzeugen. Es ist aber doch eher ungewöhnlich.

[RHBaum]

QStringList *abc = new QStringList();

unter modernen c++ nie nie nie mit new erzeugte zeiger allein im wald stehen lassen !
besser:

QScopedPointer<QStringList> ptrAbc( new QStringList());

oder die STL version

std::unique_ptr<std::list<std::string> > ptrAbc( new std::list<std::string>());

ok, eigentlich ist QStringlist ja keine std::list sondern eher ne std::dequeue

Es ist natürlich möglich diese Typen auf dem Heap zu erzeugen. Es ist aber doch eher ungewöhnlich.

Glaub es fehlt eher das verständniss, wo container ihre daten ablegen ...
DIe QStringList legt nur ihre verwaltungsdaten direkt ab, das werden nen zähler nen zeiger, bei shared copy noch nen refzaehler und bissi was mehr sein.
Also nur ne handvoll byte.
Die eigentlichen daten werden per allocator aufm heap/freestore angelegt, und man kann es nicht verhindern.

Ausnahme: std::array was ja eigentlich auch nur nen wrapper um T x[Z]; ist ....

Das heisst das zeigergerutsche (4/8 byte zeiger vs x byte Verwaltungsdaten) bringt kaum nen benfit.
Da listen per definition leer sein koennen,wird ein nullptr Value als extra Information auch überflüssig.

Und bei Qt noch extra: impliziet sharing, also copy on write ....also kopieren und nicht modifizieren macht nur ne flache kopie, aka die verwaltungsdaten werden kopiert ....
Macht lifecycle management via einfachen kopieren auch noch performant (ohne move semantic) .

Zu deutsch, zeiger auf solche listen machen nur in sehr sehr sehr speziellen Fällen Sinn ....

Ciao ...