Einmal bitte über eine kleine Klasse drüberschauen (Allocate memory)

Columbo

wenn der shared_ptr sein pointee zerstört, wird dann denn auch deallocate aufgerufen automatisch?

Nein, der Deleter wird ausgeführt. Der hat auch mit deinem Allokator nur gemein, dass sie beide die Standardversionen sind, und damit delete aufrufen. Eleganter wäre es gewesen, einen Deleter vorzugeben, der deallocate ausführt.

und wann sollte ich diesen vector auf dem stack und wann mit nem smart-pointer auf dem heap anlegen?

..was? vector alloziert seinen Speicher immer dynamisch. Ich sehe also nicht, warum du etwas was effektiv ein paar Zeiger sind, auf dem Heap anlegen solltest.

Wann sind denn alternativen für heap speicher allokierung wenn man um new uint8[SIZE] syntax herum kommen will?

Was kümmert dich denn Syntax? Wenn du Generizität möchtest, solltest du erst einmal einen Templateparameter für den Allokator bereitstellen.

Ist das std::vector da wirklich ne alternative oder bringt das zu viel overhead mit?

std::vector hält (per default-allokator) seine Daten immer auf dem Heap, std::array ist dein Stack-Freund - jeweils mit default-Allokator

Wann sind denn alternativen für heap speicher allokierung wenn man um new uint8[SIZE] syntax herum kommen will?

warum? Das ist der Standard-Weg in C++, und wenn dein allokator wenigstens austauschbar wäre (Templare-Parameter) würde ich das wenigstens noch verstehen - aber einfach so einen std::allocator im Code ist irgendwie sinnfrei

aus deinen Antworten lässt sich erkennen das dir relativ viel Grundlagen fehlen - auf der Basis so eine Klasse zu fabrizieren kann nur schlecht sein, lerne doch erstmal die Basics von C++/STL kennen bevor du von "Overhead" und "Um Syntax herum kommen" sprichst - ein erfahrener C++ Entwickler würde dein bisheriges Ergebnis so nicht nutzen wollen

Sewing

hard, bard but fair.

ich weiß, das vector auf dem heap alloziert, aber wann macht es sinn den vector durch nen smart pointer anzulegen und wann "normal" auf dem stack?

Jockelx

Sewing schrieb:

wann macht es sinn den vector durch nen smart pointer anzulegen ?

Ich lehne mich mal weit aus dem Fenster:
Nie!

wob

Sewing schrieb:

wann macht es sinn den vector durch nen smart pointer anzulegen

Wenn du sehr viele Objekte hast und die Existenz des vectors in deinem Objekt optional ist. Auf gcc/x64 ist sizeof(vector<int>)=24, ein Pointer aber hat nur size 8. Du kannst also 16 Bytes sparen, wenn du den vector dann nicht benutzt. Dafür hast du dann Overhead (sowohl Zeit, weil du einem Pointer mehr folgen musst) als auch Größe (nämlich der Extra-Pointer), falls du ihn benutzt.

Außerdem kann es sinnvoll sein, wenn du auf die Daten im vector nur selten zugreifst, aber eine große Anzahl deiner Objekte in einer zeitkritischen Routine (die nicht auf den vector zugreift) im Cache sein sollen.

Columbo

wob schrieb:

Sewing schrieb:

wann macht es sinn den vector durch nen smart pointer anzulegen

Wenn du sehr viele Objekte hast und die Existenz des vectors in deinem Objekt optional ist. Auf gcc/x64 ist sizeof(vector<int>)=24, ein Pointer aber hat nur size 8. Du kannst also 16 Bytes sparen, wenn du den vector dann nicht benutzt.

Das ist ein Trugschluss. Das dynamische allozieren eines vector s birgt auch einen overhead in der Speicherverwaltung des Betriebssystems (was signifikant werden kann, sobald wir eben viele Objekte so anlegen). Der erwartete tatsächliche Speicherbedarf muss also nicht bei 20 liegen, sondern kann auch 24 übersteigen.

wann macht es sinn den vector durch nen smart pointer anzulegen ?

wie gesagt: schaff dir erstmal ein solides Basis-Wissen - dann würde solche komischen Fragen gar nicht kommen

Sewing

Ich lese momentan den Primer von lippman.

Da wird vector sowohl auf dem Stack als in Beispielen auch mittels shared_ptr verwendet

wob

Arcoth schrieb:

wob schrieb:

Auf gcc/x64 ist sizeof(vector<int>)=24, ein Pointer aber hat nur size 8. Du kannst also 16 Bytes sparen, wenn du den vector dann nicht benutzt.

Das ist ein Trugschluss. Das dynamische allozieren eines vector s birgt auch einen overhead in der Speicherverwaltung des Betriebssystems (was signifikant werden kann, sobald wir eben viele Objekte so anlegen). Der erwartete tatsächliche Speicherbedarf muss also nicht bei 20 liegen, sondern kann auch 24 übersteigen.

Sorry, bin mir nicht sicher, ob ich dich richtig verstanden habe. Vor allem ist mir nicht klar, wo bei dir der erwartete Wert von 20 herkommt.

Angenommen, ich nutze den vector nicht (das war ja meine Annahme), dann habe ich nirgends irgendwas mit dynamischem Speicher zu tun (alle vector-pointer sind nullptr) und somit auch keinen Overhead, außer dass ich NObjekte*16 Bytes Speicher spare (oder wo ist da mein Fehler?).

Realistisch wird man den vector ja manchmal schon benutzen, sonst könnte man ihn ja komplett entfernen. Angenommen, ich habe 1e7 solche Objekte, von denen 1 Promille den vector braucht. Ich spare also 1e7*16 - 1e5*24 - 1e5*(zusätzlicher overhead) an Speicher. Jetzt ist die Frage, wie groß die Klammer ist. Ist es das, was du hier sagen willst? Oder ist meine Rechnung verkehrt?

Ich bin dabei natürlich immer davon ausgegangen, dass N_benutze_vectoren << N_objekte_gesamt ist.

Columbo

wob schrieb:

Arcoth schrieb:

wob schrieb:

Auf gcc/x64 ist sizeof(vector<int>)=24, ein Pointer aber hat nur size 8. Du kannst also 16 Bytes sparen, wenn du den vector dann nicht benutzt.

Das ist ein Trugschluss. Das dynamische allozieren eines vector s birgt auch einen overhead in der Speicherverwaltung des Betriebssystems (was signifikant werden kann, sobald wir eben viele Objekte so anlegen). Der erwartete tatsächliche Speicherbedarf muss also nicht bei 20 liegen, sondern kann auch 24 übersteigen.

Sorry, bin mir nicht sicher, ob ich dich richtig verstanden habe. Vor allem ist mir nicht klar, wo bei dir der erwartete Wert von 20 herkommt.

Man könnte ja denken, dass ich mit deiner Variante einen erwarteten Wert von $0.5 * 8 + 0.5 * (24 +$ habe.

Ich bin dabei natürlich immer davon ausgegangen, dass N_benutze_vectoren << N_objekte_gesamt ist.

Tja, das bin ich nicht.