Ich habe eine klasse, diese klasse hat eine methode, die bestimmte werte der member-variablen in ein string schreiben und zurückgeben soll, etwa so:

class myClass{
public int a,b,c;
  //... lauter tolle und nützliche sachn
  //die funktion [funktioniert nicht richtig]
  char* toString(){
    char szOutput[64];
    sprintf(szOutput, "Values: a= %i b= %i c= %i", a,b,c);
    return szOutput;
  }
};

selbstverständlich kann diese funktion nicht richtig funktionieren, weil szOutput als lokale variable auf dem stack erzeugt wird, und gleich nach dem verlassen der funktion wieder mit anderem schrott vollgeschrieben wird. Das meldet der compiler auch als warnung ("zeiger auf eine lokale variable wird zurückgegeben")
Doch wie soll ich das jetzt machen, sodass ich der funktion keinen fertigen buffer übergeben muss (will die länge des buffers nicht nochmal ausserhalb der funktion angeben, für den fall, dass sich was ändert) [So solls nicht aussehen:]

void toString(char* szOutput){
  sprintf(szOutput, "Values: a= %i b= %i c= %i", a,b,c);
}

//und dann irgendwo verwenden:
char buffer[64]; //oder doch 128... oder 256... oder was?
myObject.toString(buffer);
cout<<buffer<<endl;

Und das char array irgendwo auf den heap zu schmeissen will ich auch nicht: es wird zwar nicht gleich wieder mit schrott überschrieben, doch dann weis ich nicht, wie ich den array wieder freigeben soll...

Könnte mir jemand irgendeinen guten ratschlag geben, wie dieses problem am besten zu lösen ist? Dank im voraus.

greetz...

string toString() {
    ostringstream ss;
    ss << "Values: a=" << a << ...;
    return ss.str();
}

Oder mit einem statischen Puffer (ist nicht Threadsafe, zweiter Aufruf zerstört Ergebnis vom ersten Aufruf):

char const* toString() {
    static char buffer[64];
    snprintf(buffer, sizeof(buffer), ...);
    return buffer;
}

Oder genau so wie es nicht aussehen soll :

int toString(char* buffer, size_t length) {
   return snprintf(buffer, length, ...);
}

Was die zweite lösung angeht: für ein singleton wär's ganz okay, aber in meinem fall unbrauchbar.

Also gut, überredet, ich nehm die dritte (so wie ichs nicht haben wollte )
Wenn ich zusätzlich ne buffer-länge übergebe, kann die funktion zumindest nicht quer durch den stack irgendwelche romane schreiben, damit kann ich schon ganz gut leben

Danke sehr

falls du das Problem mit eigenen Objekten hast, gib nen std::auto_ptr mit
einem auf dem Stack erzeugten Objekt zurück, dann wird das Objekt beim verlassen
des Scopes automatisch gelöscht...

Etwa so:
std::auto_ptr<Foo> getObject() {
return std::auto_ptr<Foo>(new Foo());
}

{
std::auto_ptr<Foo> obj = bar->getObject();
} // Hier bei der schliessenden Klammer wird das Obj zerstört (Scope)

char* ToString(int nummer, char* buffer)
{
  sprintf(buffer, "%d", nummer);
  return buffer;
}

So musst du zwar trotzdem einen Buffer erstellen, allerdings kannst du die Funktion trotzdem direkt in Ausdrücken verwenden. Programmiert sich um einiges leichter.

Entweder der C++-Weg:

string toString() {
    ostringstream ss;
    ss << "Values: a=" << a << ...;
    return ss.str();
}

da wird aber der ganze string kopiert

Bleibt aber trotzdem der sauberste C++-Weg
Vom nötigen Aufwand her ähnlich und trotzdem sicher wäre wohl in diesem Fall nur ein boost::shared_array oder ein noch zu entwerfender auto_array, was wohl (gerade für den OP) etwas Overkill wäre.

Klappt ganz gut, das lass ich auch so, ausser ihr erklärt mir, warum man sowas nicht machen darf/warum es keine elegante lösung ist

thx @ all für die vielen ideen

Versteh ich in dem Zusammenhang absolut nicht...
Ganz schlechte Lösung...

und einen ziemlich großen char-buffer verwaltet, und dafür sorgt, dass die einzelnen funktionen sich nicht in die quere kommen(solang's nicht zu viele sind).

AUA aua aua aua autsch weh.
Das nicht gut.
Auf der einen Seite kannst du zwar nix garantieren ("solang's nicht zu viele sind"), auf der anderen Seite versuchst dus trotzdem. Das kann nicht gut gehen. Das üble daran ist dass du so von Anfang an einen Fehler in dein Programm reinprogrammierst, und noch übler wird es durch die Tatsache dass "solang's nicht zu viele sind" alles zu funktionieren scheint. Wenns dann aber "zuviele sind" wird es boom machen. Und ob das in einer Art und Weise passiert dass du sofort draufkommst woran es liegt ist fraglich.

Anders ausgedrückt: die Fehleranfälligkeit ist nicht akzeptabel solange sie nicht 0 ist.

#include "UC_Singleton.hpp"
#define MAX_BUFFER_LENGTH 5120

class UC_StringBuffer:public UC_Singleton<UC_StringBuffer>
{
private:
        //char-buffer
	char buffer[MAX_BUFFER_LENGTH];

        //offset to an empty segment
	int emptySegmentOffset;  

public:

	//constructor destructor
	UC_StringBuffer(){ emptySegmentOffset=0; }
	~UC_StringBuffer(){}

	char* GetBuffer(int bufferLength){

	//required buffer is too long
	if(bufferLength>MAX_BUFFER_LENGTH){
		//not enough space, returning nullpointer
		return NULL;	
	}

	//pointer to a free(?) segment of the buffer
	char* pFreeSegment; 

	if(emptySegmentOffset+bufferLength>MAX_BUFFER_LENGTH){
		//overwrite the start of the buffer
		pFreeSegment=&buffer[0];
		//update the emptySegmentOffset-offset
		emptySegmentOffset=bufferLength;
	}else{
		//append the segment
		pFreeSegment=&buffer[emptySegmentOffset];
		//update the emptySegmentOffset-offset
		emptySegmentOffset+=bufferLength;
	}

	return pFreeSegment;
	}

};

und jezt zu den genannten problemen:

Wenns dann aber "zuviele sind" wird es boom machen.

Eben nicht! zwar wird der buffer vollgemüllt, aber es kommt nicht zum absturz

Und ob das in einer Art und Weise passiert dass du sofort draufkommst woran es liegt ist fraglich.

Ich finde, es ist eigentlich einfacher, nur in dieser einen funktion nach fehlern zu suchen. Ansonsten müsste ich ja vor jedem aufruf der toString() funktion einen buffer anlegen, wo die funktion dann was reinschreiben kann. Wäre ein buffer nicht groß genug, würde alles abstürzen, und ich müsste den ganzen code nach diesem buffer absuchen.

die Fehleranfälligkeit ist nicht akzeptabel solange sie nicht 0 ist.

c++ programme sind doch immer bei char-arrays fehleranfällig, wenn man zu wenig speicherplatz reserviert, dann krachts halt... :p Soll ich jetzt deswegen auf java umsteigen?

aber danke schön schonma für die konstruktive kritik