Im Moment mache ich es so:

template<class T>
char* toString(T data, char* string) { 
	ostringstream stream;
	stream << data;
	return strcpy(string, stream.str().c_str());
}

Aber das gefällt mir nicht, da der Aufrufer die Länge des strings kennen muss. Einfach den stream.str().c_str() zurückgeben geht nicht und Speicher möchte ich auf keinen Fall in der Funktion reservieren.
Geht das irgendwie eleganter?

Ich MUSS mit char* arbeiten (WinApi). Naja, ich finds halt ziemlich grausig, dass der Nutzer immer wissen muss wie viel Speicher er reservieren muss.

nun ja, wie gesagt, du kannst die Speicherbeschaffung auch von deiner Funktion erledigen lassen und auch mit ner anderen Funktion freigeben - du könntest das auch in ner Klasse kapseln, die dann die Speicherverwaltung für den Anwender erledigt.

Das Problem ist:
std::string und char* sind nicht miteinander austauschbar. Warum also nicht eine string Klasse verwenden die es ist?

ein kleiner ansatz ist zum Beispiel
vector<char>

Hier kann man immerhin schon so sachen wie
foo(&vec[0]);
schreiben wenn man einen Buffer braucht.

Hier kann man immerhin schon so sachen wie
foo(&vec[0]);
schreiben wenn man einen Buffer braucht.

kann der string doch auch. es wurde immerhin im 2003 standard festgelegt, dass der string die daten am stück speichert(mal davon abgesehen, dass eh alle implementationen genauso arbeiten).

kann der string doch auch. es wurde immerhin im 2003 standard festgelegt, dass der string die daten am stück speichert(mal davon abgesehen, dass eh alle implementationen genauso arbeiten).

Oh, Du hast diesen Passus für std::string gefunden? Wir haben diese Zusage bisher immer nur für std::vector finden können. Sag doch mal bitte den Abschnitt in dem das steht.

otze schrieb:

kann der string doch auch. es wurde immerhin im 2003 standard festgelegt, dass der string die daten am stück speichert(mal davon abgesehen, dass eh alle implementationen genauso arbeiten).

Oh, Du hast diesen Passus für std::string gefunden? Wir haben diese Zusage bisher immer nur für std::vector finden können. Sag doch mal bitte den Abschnitt in dem das steht.

hmm du hast recht. ich war mir 100% sicher, dass ich erst vor einem monat hier einen thread zum thema string gefunden hab, wo irgendeiner der großen genau das gesagt hat. *grübel*. Naja, ich konnte es jetzt auch nicht finden. simply ignore me.

simply ignore me.

Done.

mal davon abgesehen, dass eh alle implementationen genauso arbeiten

Sicher? Es gibt in einigen Anwendungsbereichen durchaus Fürhalten für die Implementierng eines Strings als verkettete Liste und wenn der C++-Standard das Verhalten nicht festlegt könnte ich mir durchaus vorstellen, dass es entsprechend spezialisierte Implementierungen gibt.

template<class T>
char* toString(T data, char* string) {
ostringstream stream;
stream << data;
return strcpy(string, stream.str().c_str());
}

C od. C++?
strcpy is C Function

Du kannst die Funktion gerne umschreiben, so dass sie zu 100% C++ ist.

Ja, und am einfachsten ginge das, indem Du den char*-Speicher vernünftig kapselst, wie hier vorgeschlagen wurde.

Ich MUSS mit char* arbeiten (WinApi). Naja, ich finds halt ziemlich grausig, dass der Nutzer immer wissen muss wie viel Speicher er reservieren muss.

? Die Benutzung von WinAPI verbietet den Einsatz von std::string ? Sollte mich schwer wundern.

Allerdings ist es ein Leichtes (und ich würde es definitv tun), mit std::string zu "arbeiten" (also in seinem Code) und eine string2char()-Wandlung vor dem Aufruf der WinAPI-Funktion vorzunehmen (z.B. über eine ensprechende Klasse, WinAPI-Call vielleicht sogar gekapselt).
Und für char const* reicht sowieso c_str().

Sorry, ich halte dieses "ich muss mit char* arbeiten, weil ich ja WinAPI mache"-Argument für falsch und oftmals vorgeschoben, weil man selbst char* präferriert (... und dann hier genau die Fragen stellt, für deren Lösung string ja entwickelt wurde).

Gruß,

Simon2.