char* loadFromTable(unsigned int ID)
{
	HRSCR scrHandle;
	DWORD sizeByte;
	srcHandle = FindResource(GetModuleHandle(NULL), MAKEINTRESOURCE(ID), RT_STRING );
    if( scrHandle != NULL )
    {
        sizeByte = SizeofResource( NULL, rsrc );
        if( sizeByte > 0 )
        {
			sizeChar = sizeByte/sizeof(char) +1;

			strTextBuffer = new char[sizeChar];

			LoadString(GetModuleHandle(NULL) ,ID strTextBuffer,sizeChar);

			return strTextBuffer;
        }
    }

return -1;     
}

die Variable strTextBuffer liegt doch nun im Heap, oder?
Wird bei erneuten Aufruf der Funktion die Variable überschrieben, oder neuer Speicher reserviert?
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

Du müsstest sog. Smart Pointer Benutzen... dies Pointer sind intelligent, und löschen ihre Instanz sobal sie nicht mehr genutzt werden... ansonsten ist es schwer zu sagen wo du die Instanz löschen musst...es könnte ja sein das du diese Funktion nicht immer aufruftst,

1. Entwerder nutzt Smart-Pointer

2. Überdenke deine Programm Desing

3. Oder:

//Zeiger deklarieren, initalisiren
char *p=NULL;

//Funktion mit zeiger referenz
void Funktion(char *&p){
  p= new char.....
}

// löschen wenn zeiger auf eine Instanz zeigt!
if(p)
  delete p;

P.S: rufst du mehreremale die Funktion auf, wierd immer wieder neuer Speicherreserveire, und die Adresse in p gespeichert, wobei die Addresse der Alten speicehrreservierung gelöscht wird.... nicht gut!

// löschen wenn zeiger auf eine Instanz zeigt!
if(p)
  delete p;

Das 'if' ist hier überflüssig.

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 …

void Funktion(char *&p){

if(p)
 delete p;

p= new char....

}

dann ist das Problem weg, das die refernez überschrieben wird, wenn die funktione mehrermalle aufgerufen wird!!

P.S. if überflüssig? wird das überprüft beim delete obs NULL ist??

P.S. if überflüssig? wird das überprüft beim delete obs NULL ist??

Ja.

...
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.

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.

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

void Funktion(char *&p)

< Correction >

void Funktion(char *p)

< Error Detected >

delete strTextBuffer

< Correction >

delete [] strTextBuffer

< Rules >

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

Code Corrector [active] schrieb:

< Error Detected >

void Funktion(char *&p)

< Correction >

void Funktion(char *p)

Muahuahua.

Where is my head today ?

MfG
I forgot my name

Oh, God, make my sourcecode, amen.

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

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.

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 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.

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.

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();

...
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.

Ich denke ich weiss nun was zu tun ist

muli