Rückgabewert mit new angelegt, wo loeschen?

proggingmania

muli schrieb:

...
die Variable strTextBuffer liegt doch nun im Heap, oder?
...

Jepp

muli schrieb:

...
Wird bei erneuten Aufruf der Funktion die Variable überschrieben, oder neuer Speicher reserviert?
...

Beides. strTextBuffer bekommt eine neue Adresse und zeigt auf neu reservierten Speicher der Größe sizeChar.

Wenn vorher Speicher reserviert und nicht freigegeben wurde und wenn die Adresse nicht woanders zwischengespeichert wurde, dann ist dieser Speicher im Heap nicht mehr erreichbar.

muli schrieb:

...
Wenn neuer speicher reserviert wird, wie und wo delete ich den denn dann?
gehe ich hier vernünftig vor oder macht man sowas in der Regel anders?
...
muli

Im prinzip ist es egal, wo du den Speicher frei gibst.
Arrays werden mit delete [] freigegeben. Ansonsten gibst du nur ein einziges Element frei, der Rest ist dann nicht mehr zugänglich ( verwitwetes Objekt )

p.

thordk

ich seh in der funktion nirgendwo eine deklaration von strTextBuffer. also ich geh ich mal davon aus, dass diese global geschehen ist.

dadurch lässt sich das "problem" womöglich sehr leicht lösen:

delete strTextBuffer;
strTextBuffer = new char[sizeChar];

die funktion selbst kümmert sich darum, dass der speicher freigegeben wird, bevor dem pointer neuer speicher zugewiesen wird.

das ist natürlich nur dann eine lösung, wenn zwischenzeitlich nicht an irgendeiner anderen stelle ein anderer pointer auf genau diese adresse gebogen wurde. denn dann würde dieser logischerweise irgendwann ins leere greifen und dein programm fliegt dir um die ohren.

sollte das der fall sein und das design es nicht zulassen, das ganze anders zu lösen, dann ist nen smart_ptr wahrscheinlich die einfachste lösung.

Braunstein

delete[] strTextBuffer;

Als Smartpointer wäre hier wohl boost::shared_array<char> das richtige. auto_ptr geht ja nicht.

< Error Detected >

void Funktion(char *&p)

< Correction >

void Funktion(char *p)

< Error Detected >

delete strTextBuffer

< Correction >

delete [] strTextBuffer

< Rules >

new        -> delete
new []     -> delete []

LordJaxom

< Memoryleak detected >

Code Corrector [active] schrieb:

< Error Detected >
void Funktion(char *&p)
< Correction >
void Funktion(char *p)

Da kann man mal wieder sehen, wie objektorientiertes Programmieren mit steigender Komplexität vermeintlich das Denken ersetzt.
Wir schreiben einfach delete und Peng alles ist gut.
Oder hach, nehmen wir doch gleich Smartpointer, dann brauchen wir gar nicht mehr zu denken.

Muahuahua.

Where is my head today ?

MfG
I forgot my name

Oh, God, make my sourcecode, amen.

BorisDieKlinge

-> "Wir schreiben einfach delete und Peng alles ist gut. "
oder wir nehmem Java...

Aber ich will was zum denken... alles selber in der Hand haben

Simon2

Brainless Wanderers schrieb:

Da kann man mal wieder sehen, wie objektorientiertes Programmieren mit steigender Komplexität vermeintlich das Denken ersetzt.
Wir schreiben einfach delete und Peng alles ist gut....

Ha ! Da zeigt sich jahrelange Erfahrung mit großen Projekten !!

"Wir": Schreibe einmal new/malloc und x-mal "delete/free" (und bei jeder Änderung wieder ein paar mehr)
OO: Schreibe EINMAL "smartpointer" - fertig für alle Zeit!

Kann jeder selbst wählen, was komfortabler, sicherer, schöner, kürzer, übersichtlicher, .... findet.

Gruß,

Simon2.

Konrad Rudolph

Simon2 schrieb:

OO: Schreibe EINMAL "smartpointer" - fertig für alle Zeit!

Nein: Nicht OO, sondern RAII. Der Unterschied: das Laufzeitoverhead.

(OO impliziert für mich Laufzeitpolymorphie.)

Simon2

Konrad Rudolph schrieb:

Simon2 schrieb:

OO: Schreibe EINMAL "smartpointer" - fertig für alle Zeit!

Nein: Nicht OO, sondern RAII. Der Unterschied: das Laufzeitoverhead.

(OO impliziert für mich Laufzeitpolymorphie.)

Nur zur Erinnerung: ICH war nicht derjenigem der die Verwendung von smartpointern auf "OO" verkürzte.

Gruß,

Simon2.

We would have to point out:
Smart Pointers are smashing, they kick ass.

Eldarion

Konrad Rudolph schrieb:

Wieso eigentlich ne Zeiger-Referenzübergabe? Wenn man schon s 'nen Zeiger nimmt, kann man ihn auch per 'return' zurückgeben. Besser wird's dadurch natürlich auch nicht …

soll das heißen wenn man pointer returnt das das schlechter stil ist? ich finde es eig. nen gutes hilfsmittel um platz auf dem heap zusparen. was macht es für nen sinn nen riesiges objekt zu returnen? mann kann auch einfach nen pointer darauf returnen.

thordk

Eldarion schrieb:

Konrad Rudolph schrieb:

Wieso eigentlich ne Zeiger-Referenzübergabe? Wenn man schon s 'nen Zeiger nimmt, kann man ihn auch per 'return' zurückgeben. Besser wird's dadurch natürlich auch nicht …

soll das heißen wenn man pointer returnt das das schlechter stil ist? ich finde es eig. nen gutes hilfsmittel um platz auf dem heap zusparen. was macht es für nen sinn nen riesiges objekt zu returnen? mann kann auch einfach nen pointer darauf returnen.

ich finds schöner den benutzer das objekt selbst erstellen und übergeben zu lassen und referenzen zu verwenden, wenns um komplexe objekte geht.

void myfunc(Userobject &o);

// statt

Userobject* myfunc();

Simon2

Eldarion schrieb:

...
soll das heißen wenn man pointer returnt das das schlechter stil ist? ...

Ich denke, "verteilte Zuständigkeiten" machen oft eine Menge Probleme und dazu gehören auch (und gerade) die Trennung von "Erzeuger" und "Löscher". ("... Der Herr hat's gegeben, der Herr hat's genommen ..." )

Gruß,

Simon2.

muli

danke für eure Bemühungen!

Ich denke ich weiss nun was zu tun ist

muli