realloc
-
Ich habe ein paar Fragen zu realloc unter C++:
Ja, ich weiß das ist C und es kommt mit Konsturktoren etc nicht klar.
Ich brauche es aber nur für Arrays mit build-in types.Vor allem interessiert mich die Geschwindigkeit der Funktion. Insebesondere ob dabei Elemente kopiert werden. www.opengroup.org schreibt dazu auch etwas: ...(possibly moved)... Soll das heißen vielleicht,vielleicht nicht und wenn ja, kann ich es irgendwie trotzdem beeinflussen? - Wäre ja bei relativ großen Array wahnsinnig unpraktisch. Einen neuen Array anlegen und kopieren kann ich selbst.
Es soll mal für String Manipulationen benutzt werden.
Ich muss zum Beispiel die letzten Elemente abschneiden.
Reagiert realloc mit size < sizearray korrekt, sprich mit einer Verkleinerung des Arrays und wenn ja, an welchem Ende, bzw. kann ich das Ende beeinflussen?Und zu guter letzt: Sollte bei der Freigabe dann free oder delete verwendet werden oder ist der Effekt der selbe?
-
1.) delete nur für new => ...
2.) Mit new wird ein zusammenhängender Speicherblock reserviert. Das heisst,
wenn "hinter" dem bisherigen Speicherblock noch Platz ist, dann gut, ansonsten
muss dann natürlich umkopiert werden.3.) Detaillierter Einflussnahme ist nur dann möglich wenn du dir deine eigene
Speicherverwaltung baust.Generell verhält sich realloc unter C++ genauso wie unter C.
-
1.) delete nur für new => ...
Ja mag ja sein dass ich meinen Speicher mit new allokiert habe. Aber ich habe mit realloc dran rumgebosselt. Und nu? Oder muss ich dann gleich auch auf free umsteigen?
2.)Mit new wird ein zusammenhängender Speicherblock reserviert. Das heisst,
wenn "hinter" dem bisherigen Speicherblock noch Platz ist, dann gut, ansonsten
muss dann natürlich umkopiert werden.Ich nehme mal an das bezieht sich jetzt auch auf malloc - da new ja malloc aufruft.
3.) Detaillierter Einflussnahme ist nur dann möglich wenn du dir deine eigene
Speicherverwaltung baust.Lass ma
-
nirsaja schrieb:
1.) delete nur für new => ...
Ja mag ja sein dass ich meinen Speicher mit new allokiert habe. Aber ich habe mit realloc dran rumgebosselt. Und nu? Oder muss ich dann gleich auch auf free umsteigen?
Damit bewegst du dich schon im Gebiet "undefiniertes Verhalten" - new/delete können die alten C-Funktionen malloc()/free() nutzen, dann klappt das ohne Probleme, sie können aber auch ihre eigene Speicherverwaltung implementieren, in dem Fall dürfte schon der realloc()-Aufruf zu Problemen führen.
2.)Mit new wird ein zusammenhängender Speicherblock reserviert. Das heisst,
wenn "hinter" dem bisherigen Speicherblock noch Platz ist, dann gut, ansonsten
muss dann natürlich umkopiert werden.Ich nehme mal an das bezieht sich jetzt auch auf malloc - da new ja malloc aufruft.
Niemand schreibt vor, daß new wirklich malloc verwendet, um an seinen Speicher heranzukommen.
-
Damit bewegst du dich schon im Gebiet "undefiniertes Verhalten"
Gut, dann darf man also gespannt sein
Und wie verhält es sich nun mit den Enden beim Abschneiden, bzw. mit der Geschwindigkeit?
-
nirsaja schrieb:
Damit bewegst du dich schon im Gebiet "undefiniertes Verhalten"
Gut, dann darf man also gespannt sein
Ich hoffe, dir ist klar, was "undefiniertes Verhalten" bedeutet - mit viel Glück funktioniert's, aber niemand kann dir garantieren, daß es morgen immer noch funktioniert.
Und wie verhält es sich nun mit den Enden beim Abschneiden, bzw. mit der Geschwindigkeit?
Afaik schneidet realloc() den hinteren Bereich des Ziels ab. (und die Geschwindigkeit hängt davon ab, ob hinter dem Pointer noch genug Platz ist (wenn ja, wird vermutlich nichts verschoben) und wie gut die Speicherumlagerung implementiert ist.
-
std::vector
std::string
-
Afaik schneidet realloc() den hinteren Bereich des Ziels ab. (und die Geschwindigkeit hängt davon ab, ob hinter dem Pointer noch genug Platz ist (wenn ja, wird vermutlich nichts verschoben) und wie gut die Speicherumlagerung implementiert ist.
Gut, beim Abschneiden wird ja kein neuer Speicher benötigt werden und demnach auch keine Verschiebung nötig sein - Ansonsten wir die Implementierung schon in jedem schneller sein als ich.
Um das undefinierte Verhalten zu umgehen könnte man ja wieder ganz auf malloc/realloc/free zurückkommen - jedenfalls in den Fällen wo realloc nötig sein wird.
Der dadurch entstehende Mischmasch ist allerdings fast schon genauso übel.
-
std::vector
std::string...
-
Wenn der Mischmasch konsequent ist (malloc -> placement new -> free bzw. new -> (!kein! realloc) -> delete) funktioniert es wenigstens
-
nirsaja schrieb:
std::vector
std::string...
Darfst du die Sachen nicht benutzen?
-
Darfst du die Sachen nicht benutzen?
Würde ich fragen, wenn ich STL Container nehmen wollte?