const char* nach char*



  • Moin ich bins nochmal!

    ich habe eine funktion die einen parameter vom typ char* erwartet und einen string, den ich an die funktion übergeben will. wenn ich den string aber als

    s.c_str()
    

    übergebe erhalte ich eine fehlermeldung. wie kann ich den string in einen char* typ umwandeln?



  • char CharArray[256]; //Platz fuer 255 Zeichen reservieren + \0
    string MyString = "hallo leider gehts nicht anders");
    
    strncpy(CharArray, MyString.c_str(), 255);
    

    So sollte es klappen, ist aber nicht wirklich schön 😞



  • das tut mir im herzen weh, gehts echt nich anders?
    ansosnten danke!



  • Hast du schonmal const_cast<>() versucht?



  • Original erstellt von cerebrum:
    Hast du schonmal const_cast<>() versucht?

    bevor er zu const cast greift sollte er

    string s = "Hallo";
    char * str =  &s[0];
    

    problem hier bei ist (genau so wie beim const_cast) das stategien wie "Copy On Write" fehler verurschen die sich nicht schnell finden lassen
    der code wird dadurch unportabel usw.



  • ich hab das problem auch schon mal gehabt. ich habs dann auch mit casten gelöst, das ist aber bestimmt nicht die schoene variante.

    ich denke, korigiert mich wenn ich falsch liege, das string.c_str() nur einen pointer auf die interne representation des strings in dem string objekt liefert. das würde bedeuten das wenn ich den erhaltenen cstring caste und verändere auch der ursprungsstring verändere.

    wenn man den cstring also nicht verändern will, dann kann man ihn auch als const char* nehmen. versuch doch mal ob du die funktionen schreiben kannst das sie einen constanten charpointer nehmen.



  • @Dimah: ich glaube nicht, dass hier ein COW-Fehler auftritt, da s[0] doch eigentlich bereits als schreibzugriff angesehen werden sollte. und c_str() ist doch nichtmal garantiert der selbe string, da string nicht nullterminiert sein muss, oder wie seh ich das?



  • zumindest gehts mit einem const_cast ---



  • Original erstellt von Mr. N:
    c_str() ist doch nichtmal garantiert der selbe string, da string nicht nullterminiert sein muss, oder wie seh ich das?

    richtig, es muss nicht derselbe speicher sein, aber derselbe string 😉



  • und außerdem: was ist an KPCs idee auszusetzen? wenn du unbedingt ein char* brauchst, ... (selbst schuld, mach es wie KPC)
    statt 256 machst du dann einfach mit new und länge des strings.



  • @davie: Die Frage ist auch die Semantik. (geiles wort, wa?) Verlangt die Funktion char * ist doch offentsichtlich (in a C++ programmers point of view), dass er verändert wird. c_str() kann nun muss aber nicht derselbe speicher sein. KPCs Lösung ist perfekt - solange die Semantik stimmt. Dimahs Lösung hat in meinen Augen jedoch nur ein Problem: der erhaltene Pointer zeigt nicht notwendigerweise auf einen nullterminierten String. WAHRSCHEINLICH aber ist hier das Problem, dass irgendein unsauberer Bibliotheksprogrammierer das const vor char * (oder nach dem char, nach belieben :D) vergessen hat und es hier also weg muss. DANN sollte man auf jeden Fall const_cast einsetzen.



  • ich gehe davon aus, dass jeder bibliotheksprogrammier sauber programmiert, was const angeht zumindest. außer ich kenn ihn persönlich.



  • Dimahs Lösung ist gefährlich.
    denn was wenn std::string als list oder ähnliches implementiert ist?
    seine Lösung wäre bei einem vector perfekt.

    das bringt uns der Lösung des problems schon näher.
    da hier definitiv ein char* gebraucht wird, wäre es uU eine gute Idee gleich vector<char> zu verwenden!

    const cast ist auch käse!
    funktioniert nur dann, wenn Dimahs Lösung auch funktioniert, und dann ist Dimahs Lösung schöner!

    das mit dem vielen umkopieren ist mir persönlich zuwider...



  • vector<char> aber auch nur nach dem defect report o.ä.
    eine andere lösung wäre, eine eigene string klasse zu machen 😉



  • @Davie:

    ich gehe davon aus, dass jeder bibliotheksprogrammier sauber programmiert, was const angeht zumindest. außer ich kenn ihn persönlich.

    ich aber nicht 😃



  • wie du meinst.
    seltsam, jetzt hat mich das forum rausgeschmissen?



  • seltsam...
    naja, wenn du meinst, ein const_cast ist angebracht...
    ich weiß nicht genau, wie das ist, ob ein const_cast alleine schon undefiniertes verhalten erreicht, wenn die zugrunde liegenden Daten wirklich const sind?



  • const_cast führt nur zu undefiniertem verhalten, wenn man auf den entconsteten dingsda schreibend zugreift



  • dann führt aber nie const_cast zu dem undefinierten verhalten

    /edit: sondern nur das dereferenzieren "danach"

    [ Dieser Beitrag wurde am 19.04.2003 um 00:59 Uhr von davie editiert. ]



  • Original erstellt von Mr. N:
    @Dimah: ich glaube nicht, dass hier ein COW-Fehler auftritt, da s[0] doch eigentlich bereits als schreibzugriff angesehen werden sollte. und c_str() ist doch nichtmal garantiert der selbe string, da string nicht nullterminiert sein muss, oder wie seh ich das?

    stimmt beides
    ahja AFIK gabs ne version vom gcc wo das interne char array in std::string nicht immer nullterminiert war

    was ist jetzt besser
    c_str() + const_cast und COW fehler riskieren oder &s[0] und fehlende nullterminierung reskieren

    natürlich kann man beide probleme so lösen

    s[0]; // hoffe das der compilier troz seiteneffekt nicht wegoptimiert
    char * c = const_cast<char*>( s.c_str() );
    

    bzw.

    s.c_str(); // hoffe das der compilier troz seiteneffekt nicht wegoptimiert
    char * c = &s[0];
    

    Original erstellt von Shade Of Mine:
    **Dimahs Lösung ist gefährlich.
    denn was wenn std::string als list oder ähnliches implementiert ist?
    **

    nicht besprechens wert der fall, oder kenns du ein bsp für?


Anmelden zum Antworten