Kurze Frage über Char-Arrays



  • Hallo, ich habe eine kleine Frage zu folgendem:

    char *text;
    
    text = "Du Affe!!!";
    cout << text << endl;
    

    Meine Frage: Wieso muss man text nicht mit delete löschen?



  • Weil du keinen Speicher allozierst.



  • Du löschst nur Sachen mit delete, die du mit new erstellt hast.



  • Stringliterale leben im statischen Speicher und sind fest ins Programm einkompiliert.
    Deine Zuweisung ist uebrigens ab C++11 nicht mehr erlaubt, da die implizite Konvertierung zu char* entfernt wurde. Stringliterale sind vom Typ char const[N], wobei N die Anzahl der Zeichen + 1 fuer den Nullterminator ist.



  • Kellerautomat schrieb:

    .
    Deine Zuweisung ist uebrigens ab C++11 nicht mehr erlaubt, da die implizite Konvertierung zu char* entfernt wurde.

    Interessant zu wissen. War mir nicht bekannt. Das dürfte großen Einfluss auf bestehenden Code haben.



  • TNA schrieb:

    Das dürfte großen Einfluss auf bestehenden Code haben.

    Ja, auf schlechten Code. Diese Zuweisung kann nur schlecht sein - String-Literale zu verändern führt zu UB.


  • Mod

    Darum sollte dir jeder Compiler diese Zuweisung schon seit 13 Jahren vor der Änderung als deprecated angemeckert haben.



  • String-Literale zu verändern ist natürlich Mist. Bei so einer Zuweisung muss man natürlich wissen was man tut. Sauberer und konsistenter ist es jetzt mit Sicherheit. Wenn aber Abwärtskompatibilität und C-Kompatibilität nicht mehr das entscheidende Kriterium sind, könnte man sicherlich noch andere Sachen anpacken. Auf der anderen Seite hört man oft als entscheidendes Argument für C++, das uralter Code noch kompiliert.



  • Sobald etwas in bestehenden Codes geändert werden soll, macht der Standard es zuerst deprecated und entfernt es dann, damit die Entwickler noch Zeit haben das alles zu ändern.

    Leute die sowas schreiben kommen wohl aus den wilden Neunzigern.



  • SeppJ schrieb:

    Darum sollte dir jeder Compiler diese Zuweisung schon seit 13 Jahren vor der Änderung als deprecated angemeckert haben.

    OK, dann ist das natürlich etwas anderes.



  • TNA schrieb:

    Auf der anderen Seite hört man oft als entscheidendes Argument für C++, das uralter Code noch kompiliert.

    Ähm... nein? <iostream.h> und Konsorten kompilieren nicht.


  • Mod

    TNA schrieb:

    Auf der anderen Seite hört man oft als entscheidendes Argument für C++, das uralter Code noch kompiliert.

    Selbst im allerersten C++ ließen sich nur die allereinfachsten C-Programme übersetzen. Schon ein einfaches malloc ging nicht mehr.

    Es sind jedoch keine großen Änderungen nötig. Beim malloc musste man eben korrekt casten. Hier muss man eben den korrekten Datentyp benutzen (oder zur Not tut es auch ein reinterpret_cast).

    Wer jahrelang nicht auf "deprecated"-Warnungen hört, ist eben selber schuld und hat dann irgendwann alle Änderungsarbeit auf einen Schlag.

    Wenn aber Abwärtskompatibilität und C-Kompatibilität nicht mehr das entscheidende Kriterium sind, könnte man sicherlich noch andere Sachen anpacken.

    Was fehlt dir denn?



  • Wir haben noch Teile, der im Kern auf etwa 15 Jahre altem C-Code basieren. Ich weiß allerdings nicht genau, wie oft der noch angepackt wurde, aber sehr aufwändige Anpassungen wurden da mit Sicherheit nicht gemacht.



  • TNA schrieb:

    Wir haben noch Teile, der im Kern auf etwa 15 Jahre altem C-Code basieren. Ich weiß allerdings nicht genau, wie oft der noch angepackt wurde, aber sehr aufwändige Anpassungen wurden da mit Sicherheit nicht gemacht.

    Die alten C-Dateien werden mit einem C Compiler compiled, andere C++ Teile mit dem C++ Compiler.
    Solange die Headerdateien kompatibel sind, kann man das auch linken.



  • [quote="Marthog"]

    TNA schrieb:

    Die alten C-Dateien werden mit einem C Compiler compiled, andere C++ Teile mit dem C++ Compiler.
    Solange die Headerdateien kompatibel sind, kann man das auch linken.

    Das ist bei uns keineswegs durchgehend so klar getrennt. Mittlerweile wird fast alles mit einem C++ Compiler übersetzt.


Log in to reply