calloc / realloc (string array)

Danke erst mal

Das ich das ganze mit
string str = new string[x];*
lösen kann, das weiß ich ja. Es gibt aber beispielsweise keine möglichkeit eine vergrößerung vorzunehmen. Ich weiß auch wohl, dass sich das mit einer for(;;;) Schleife recht schnell lösen lässt, aber das ist nicht Sinn der Sache. Ich möchte viel mehr verstehen warum realloc nicht funktioniert und was ich machen kann, damit es funktioniert.

calloc / malloc / realloc sind C-Funktionen für PODs. std::string ist aber kein POD. In C++ gibts dafür new[] , delete[] und std::vector<> . Die kommen alle auch mit nicht-PODs klar.

Das Hauptproblem bei Dir ist, dass die string Objekte gar nicht richtig initialisiert wurden. In deinem Array steht Müll (ungültiger Zustand eines string -Objektes) drin. Das zweite Problem ist, dass realloc ggf die Daten bitweise zu einem neuen Block kopiert und den Kopier-Konstruktor und Destruktor der Klasse übergeht.

Gruß,
SP

Kronos_m schrieb:

Das ich das ganze mit
string str = new string[x];*
lösen kann, das weiß ich ja. Es gibt aber beispielsweise keine möglichkeit eine vergrößerung vorzunehmen.

--> std::vector<std::string>

(Es kann so einfach sein)

Gruß,
SP

Kronos_m schrieb:

Ich möchte viel mehr verstehen warum realloc nicht funktioniert und was ich machen kann, damit es funktioniert.

Gar nichts. Es geht nicht. realloc ist unberechenbar und für non-PODs einfach nicht zu gebrauchen. Das Problem mit realloc ist, dass es sich die Freiheit nimmt, den alten Speicherblock freizugeben und einen neuen zu reservieren -- ohne dass man als Nutzer die Gelegenheit bekommt, die Objekte ordnungsgemäß zu kopieren/zerstören.

Und selbst wenn Du eine weniger freche realloc Funktion hättest -- eine, die vorher zurückfragt, wie die Daten denn zu kopieren sind, falls der Block nicht einfach vergrößert werden kann -- wäre es den Aufwand gegenüber std::vector einfach nicht wert. Da haben sich schon ein paar Leute die Zähne dran ausgebissen.

Gruß,
SP

Gut, danke erstmal. Das mit den PODS klingt einleuchtend.
Dann schreibe ich mir die Funktion zum Array vergrößern eben doch selbst. Das ist schade.

Sebastian Pizer schrieb:

In deinem Array steht Müll

Meiner Kenntnis nach steht in den Speicherstellen, die mit calloc / realloc reserviert werden Nullen. Weil die Funktionen jedes Bit der Speicherstellen auf Null setzen. Zumindest laut Referenz.

theta

Dann schreibe ich mir die Funktion zum Array vergrößern eben doch selbst. Das ist schade.

Nimm doch, wie schon erwähnt, std::vector<T>!!!!
Der geht für alle Typen (solange sie kopierbar sind) und wenn nötig, kannst Du mit &vec[0] direkt auf den Speicher zugreifen (z.B. für C Interoperabilität).
Simon

Hi theta,

ich weiß doch
Habe euch wohl etwas verwirrt Aber zu Übungszwecken schreibe ich mir gerade meine eigene vector Klasse. Dann wäre es ja blöd, wenn ich sie benutzen würde. Über Sinn und Unsinn kann man natürlich streiten.
Auf jeden Fall ist das der Grund, warum ich den speicher selber verwalten möchte

Setze das jetzt gerade mit new[] um!

theta

Ok... das erklärt natülich einiges..

Meiner Kenntnis nach steht in den Speicherstellen, die mit calloc / realloc reserviert werden Nullen. Weil die Funktionen jedes Bit der Speicherstellen auf Null setzen. Zumindest laut Referenz.

nur calloc initialisiert mit 0

Nexus

kronos_m schrieb:

Sebastian Pizer schrieb:

In deinem Array steht Müll

Meiner Kenntnis nach steht in den Speicherstellen, die mit calloc / realloc reserviert werden Nullen. Weil die Funktionen jedes Bit der Speicherstellen auf Null setzen. Zumindest laut Referenz.

Nullen sind Müll, wenn es um einen std::string geht**!** Du darfst Objekte von Non-POD-Klassen nicht manuell initialisieren, dafür gibt es Konstruktoren.

kronos_m schrieb:

Setze das jetzt gerade mit new[] um!

Ein Tipp: std::vector reserviert meistens für ein bisschen mehr Elemente Speicher als tatsächlich belegt werden. Wenn du das auch machst, kannst du dir in den meisten Fällen teure Reallokationen sparen, wenn du nur ein Element anhängst.