Wenn ich es so mache:

std::string name = "john";

char pName[ sizeof(name) ];

strcpy( pName, name.c_str() );
/*
 * benutze pName...
 *
 */

dann stürtzt das Programm ab.

Lösungsvorschläge?

Probiers mit name.size() statt sizeof(name)

Jau das damit scheints zu gehn. Das ging aber schnell. Danke

MfG SideWinder

...
Wenn ich es so mache:
...

Ehrlich gesagt, würde ich das überhaupt nicht machen.
string ist ein "dynamischer Container", d.h. zur Laufzeit des Programms ändert sich die Speichergröße permanent.
Ob das angelegte char-Array die richtige Größe hat, hängt davon ab, wann string::size() aufgerufen wird....
Man KANN das natürlich machen, aber man muß sehr vorsichtig sein und schnell was "falsch" machen...
Einige mögliche Probleme, die mir spontan einfallen:

• Wenn man z.B. später den "name" verlängert und es nochmal in pName kopieren will, schreibt man über den Speicherbereich von pName hinaus => Fehler in den Daten oder Programmabsturz oder ....
• mit string::size() bekommt man die Anzahl der Zeichen in String .... bei der Anlage eines char-Arrays aber darf man "die abschließende 0" nicht vergessen; wenn, dann sollte man also "size()+1" verwenden.
• ...

Wenn es nur darum geht, den Wert als char* zu bekommen (z.B. weil die aufgerufene Funktion das braucht), ist man oftmals mit c_str() besser bedient (WENN die aufgerufene Funktion ein const char* akzeptiert).

Gruß,

Simon2.

Naja wieso, wenn er einen Compiler hat, der VLAs als Erweiterung unterstützt.

Dennoch ist das nicht zu empfehlen, da der Code somit unportabel wird.

sly schrieb:

Ich will einen string in einen char* wandeln

Wozu willst du das denn machen? Ein std::string kann auch als char* gehandelt werden &name[0].
Wenn es darum geht den String zu sichern, dann nimm wieder std::string.

Wozu willst du das denn machen? Ein std::string kann auch als char* gehandelt werden &name[0].

Ich lese immer wieder dass string weder garantiert, dass die Daten an einem Stück im Container liegen müssen, noch dass die Daten im Container schon nullterminiert sind. Demnach würde ich das nicht unbedingt empfehlen

Ich lese immer wieder dass string weder garantiert, dass die Daten an einem Stück im Container liegen müssen

Ich denke aber schon, dass dies der Fall ist. Oder wie erklärst du dir Funktion data()? Zudem muss std::basic_string den Anforderungen einer Sequenz entsprechen.

LordJaxom schrieb:

noch dass die Daten im Container schon nullterminiert sind.

Davon hat auch niemand gesprochen. Ich weiss schon, man verbindet char* sofort mit C-String, das ist aber nicht wirklich korrekt. Ein C-String wird nunmal durch char* repräsentiert, char* ist jedoch nicht gleichzusetzen mit C-String.

LordJaxom schrieb:

Ich lese immer wieder dass string weder garantiert, dass die Daten an einem Stück im Container liegen müssen

Ich denke aber schon, dass dies der Fall ist. Oder wie erklärst du dir Funktion data()? Zudem muss std::basic_string den Anforderungen einer Sequenz entsprechen.

der standard ist so formuliert, dass eine derartige implementation (daten an einem stück und nullterminiert) eine offensichtliche wahl ist. der sequenzaspekt erfordert das aber nicht, auch deque bildet sequenzen. außerdem macht der standard keine explizite aussage über die komplexität der data und c_str memberfunktionen. prinzipiell ist es denkbar, dass die entsprechenden arrays erst beim aufruf konstruiert werden.

groovemaster schrieb:

Ich denke aber schon, dass dies der Fall ist.

was meinst du? dass der standard das garantiert, oder das jede existierende implmentation sich so verhält?

Davon hat auch niemand gesprochen. Ich weiss schon, man verbindet char* sofort mit C-String, das ist aber nicht wirklich korrekt. Ein C-String wird nunmal durch char* repräsentiert, char* ist jedoch nicht gleichzusetzen mit C-String.

Ich ging dreisterweise davon aus, da der OP mit strcpy arbeitete, welches zum einen auf die nullterminierung der Quelle angewiesen ist und zum anderen selbst das Ziel nullterminiert.

was meinst du? dass der standard das garantiert, oder das jede existierende implmentation sich so verhält?

Dass jede existierende Implementation sich so verhält. Eine Garantie ist mir seitens des Standards jedenfalls nicht bekannt.

camper schrieb:

was meinst du? dass der standard das garantiert, oder das jede existierende implmentation sich so verhält?

Dass jede existierende Implementation sich so verhält. Eine Garantie ist mir seitens des Standards jedenfalls nicht bekannt.

Bei der Programmierung sollte man sich darauf beschränken, was der Standard definiert. Daß die existierenden Impelentationen eine gewisse Eigenschaft hat (habt ihr auch alle exisitiernden C++-Compiler getestet?), garantiert nicht, daß die nächste Version dieses Verhalten zeigt.

Im übrigen sollte man beachten, daß ein std::string häufig Referenzgezählt ist und daher eine Veränderung der Daten nicht zu empfehlen ist. Es hat schon seinen Grund, warum die data()-Methode einen const-Zeiger liefert.

Im übrigen hat die Originallösung noch einen Fehler. std::string::size() liefert die Länge des Strings. Ein strcpy des c_str()-Zeigers kopiert aber ein Zeichen mehr. Ihr habt den Nullterminator vergessen, welcher von c_str() garantiert wird, aber nicht zur Stringlänge gehört.

Tntnet

Das erspart das (möglicherweise ineffiziente) Gefrickel mit c_str oder data.

std::copy (str.begin (), str.end (), cstr);

geht auch

str.copy(cstr, str.size());

Tntnet

template <typename CharT>
std::auto_ptr<CharT> string_to_array (const std::basic_string<CharT>& str)
{
    CharT* cstr = new char[str.size () + 1];
    std::copy (str.begin (), str.end (), cstr);
    cstr[str.size ()] = 0;
    return std::auto_ptr<CharT> (cstr);
}

Das erspart das (möglicherweise ineffiziente) Gefrickel mit c_str oder data.

array new und auto_ptr? keine gute idee.

Bei der Programmierung sollte man sich darauf beschränken, was der Standard definiert.

Naja, mit dieser Einstellung wirst du in der Praxis aber schnell an Grenzen stossen. Es geht ja nicht darum, dass irgendetwas Verbotenes gemacht werden soll.

tntnet schrieb:

Im übrigen sollte man beachten, daß ein std::string häufig Referenzgezählt ist und daher eine Veränderung der Daten nicht zu empfehlen ist.

Was meinst du mit "eine Veränderung der Daten nicht zu empfehlen ist"? Du kannst jedes String Objekt ganz normal per op [] ändern.

Was meinst du mit "eine Veränderung der Daten nicht zu empfehlen ist"? Du kannst jedes String Objekt ganz normal per op [] ändern.

Er meinte höchstwahrscheinlich die Änderung der Daten in (char*)&str[0] oder const_cast<char*>(str.data()), also das worum es in diesem Thread die meiste Zeit ging

array new und auto_ptr? keine gute idee.

Izz, stimmt. Dann halt mit normalem Zeiger:

template <typename CharT>
CharT* string_to_array (const std::basic_string<CharT>& str)
{
    CharT* cstr = new char[str.size () + 1];
    std::copy (str.begin (), str.end (), cstr);
    cstr[str.size ()] = 0;
    return cstr;
}

Ich wollte dem Anwender Arbeit abnehmen.
BTW, beim Test hatts wohl nur deshalb nicht gekracht, weil die Benutzung so aussah:

std::cout << string_to_array (std::string ("asdf")).release () << std::endl;