3. von string nach char* umwandeln

von string nach char* umwandeln

  • ?

    ö
    wie meinst du das?

    0
  • ?

    So geht es:

    std::string s = "Hallo";
char buffer[100];
sprintf(buffer, "%s", s.c_str());

    Das buffer Array solltest du vielleicht noch dynamisch (new) erstellen.

    0
  • ?

    Und so macht man es dynamisch:

    std::string s = "Hallo";
char* buffer = new char[s.length() + 1];
sprintf(buffer, "%s", s.c_str());
// hier buffer bearbeiten
delete[] buffer;
    0
  • ?

    Hey Schlechter Prog.
    Ich danke dir, hat wunderbar geklappt. So schlecht bist du doch gar nicht.

    0
  • K

    Hallo,

    man könnte zwei dinge machen:

    Wenn Du Dir sicher bist das NUR GLESEN wird:

    const_cast<char*>(temp.c_str());

    Ansonsten:

    Länge des strings holen
    speicher allokieren
    strcpy (besser strncpy) verwenden zum kopieren
    und diesen Speicher übergeben.

    0
  • ?

    Benutze statt dem sprintf was "schlechter Programmierer" vorschlägt besser strcpy.

    strcpy(buffer, s.c_str());

    🕶

    0
  • O
     

    std::string str = "Hallo Spencer!";
const char* bufBegin = str.c_str();
std::vector<char> vec(bufBegin, bufBegin + str.length() + 1);
olleCFunktion(&vec[0]);

    Auch vier Zeilen, allerdings exceptionsicher...

    0
  • K

    Hm, ich arbeite viel zu wenig mit vector...

    ... und werde auch immer von op void immer wieder erinnert das es sowas gibt 🤡

    thx

    0
  • ?

    eine "olle C Funktion" wird wohl keine Exception werfen. 😡

    0
  • R

    noch ein paar Dinge zu std::memcpy vs. std::strcpy vs. std::strncpy

    std::memcpy ist für das kopieren von Strings mein Favorite, wenn ich die String länge kenne. Das liegt daran, dass std::memcpy oft optimiert ist zB. mit SIMD.

    std::strcpy besitzt die Gefahr einen Bufferoverflow zu produzieren.

    std::strncpy hat die Problematik, mit der 0-Terminierung. Manchmal wird garnicht terminiert, manchmal zu viel und Optimierung mit SIMD ist auch nicht möglich.

    Also ich würde std::memcpy benutzen an deiner Stelle.

    0
  • P

    Ist &vector[0] eigentlich endlich im Standard angekommen? 🙄

    @kingruedi - guter beitrag, man sollte aber hinzufügen: Falls man die Länge des String kennt, sonst bringt es nix (besser: praktisch nie was).

    0
  • O

    Dass Vektoren ihre Elemente an einem Stück speichern müssen, wurde nachträglich so festgelegt (im Library TR AFAIK). Und da Vektoren verschwindend wenig Overhead haben und man mit ihnen einfach umgehen kann sind sie IMHO etwas, das man sich statt new[]/delete[] angewöhnen sollte, auch wenn Exceptions zum Zeitpunkt des Code-Schreibens noch kein Problem sind (wie ichs ja leider im Beispiel angedeutet habe). Eine schnellere und vergleichbar sichere Möglichkeit wären natürlich C99s Variable Length Arrays, aber dass die es jemals nach C++ schaffen, bezweifle ich leider 😞

    0
  • H

    Dass Vektoren ihre Elemente an einem Stück speichern müssen, wurde nachträglich so festgelegt (im Library TR AFAIK).

    Standard-Library Defect Report Nummer 69. Stadium ist mittlerweile TC. Sprich:

    TC - (Technical Corrigenda) - The full WG21 committee has voted to accept the Defect Report's Proposed Resolution as a Technical Corrigenda. Action on this issue is thus complete and no further action is possible under ISO rules.

    Die Sache ist also auch von der theoretischen Seite her erledigt.

    operator void schrieb:

    Eine schnellere und vergleichbar sichere Möglichkeit wären natürlich C99s Variable Length Arrays, aber dass die es jemals nach C++ schaffen, bezweifle ich leider 😞

    Also wenn ich Bjarne Stroustrups Artikel im CUJ x/Irgendwas richtig interpretiert habe, dann komme VLAs definitiv nicht in den neuen Standard.

    Matthew Wilson beschreibt im CUJ vom Dezember 2003 aber eine Implementation für "Efficient Variable Automatic Buffers" (leider nicht online). Vielleicht gefällt sie dir ja. Die Implementation findest du in der STLSoft-Lib (www.stlsoft.org)

    0
Anmelden zum Antworten