cin.getline() initialisiert array neu
-
Hab mal ne Frage zu folgendem Code, ich kann mehr als 19 Zeichen in "zeile" schreiben, heist das das cin.getline() die übergebene Variable neu deklariert?
IDE = Code::Blocks
#include <iostream> using namespace std; int main() { char zeile[10]; cout << "Insert string, end with ENTER..." << endl; // Einlesen //cin >> zeile; cin.getline(zeile,100); // Ausgeben cout << endl << zeile << endl; system("pause"); return 0; }
-
Nein, dass heisst, dass Du Speicher überschreibst, der Dir nicht gehört.
-
char zeile[10]; ... cin.getline(zeile,100);Um solche Fehler zu vermeiden, nimmt man für die maximale Zeilenlänge eine Konstante und benutzt die dann statt der numerischen Werte oder wählt gleich die Variante für std::string:
string s; getline(cin, s);
-
jencas schrieb:
char zeile[10]; ... cin.getline(zeile,100);Um solche Fehler zu vermeiden, nimmt man für die maximale Zeilenlänge eine Konstante und benutzt die dann statt der numerischen Werte oder wählt gleich die Variante für std::string:
string s; getline(cin, s);Ich glaube, ihm ist schon klar, dass er da mehr reinschreibt, als er eigentlich sollte. Er wundert sich (Glaskugel) vermutlich nur, wieso das so "anstandslos" funktioniert.
In C++ gibt es für klassische Arrays keine Längenprüfung. Wenn Du auf Elemente eines Arrays zugreifst die es nicht gibt, bekommst Du vom Compiler keine Fehlermeldung.
Das Verhalten Deines Programms ist dann aber undefiniert. Undefiniert heisst, es kann alles mögliche passieren...
-
Tachyon: danke, das wollte ich wissen...
-
Tachyon schrieb:
Undefiniert heisst, es kann alles mögliche passieren...
Oft gesehen ist z.B. ein segmentation fault/violation. Das Programm schmiert dir dann ab, nachdem es eine entprechende Fehlermeldung in den Äther geschrien hat.
Ein anderes Problem hatte ich neulich: das Programm hat sich sang- und klanglos verabschiedet. Allerdings nur wenn man nicht im Debug-Modus kompiliert hat, denn im Debugmodus liefs ohne Probleme (!)
Die Funktion in der der Fehler passiert ist wurde (ohne Debugmodus) einwandfrei bis zum Ende ausgeführt (letzter Befehl war ein cout-statement), allerdings wurde der nächste Befehl nach der Funktion (auch ein cout statement) nie erreicht. Mit den Erkenntnissen hatte ein Kollege mir den Schlamassel übergeben.
Ergebnis: die Funktion wimmelte vor char-Arrays, printf()'s und all dem grausigen Geraffel ohne irgendwelche Längenchecks. An einer Stelle ging das dann auch schief, im Release-Modus wurde die Rücksprungadresse überschrieben, im Debug-Modus hats nur die Debuginformationen erwischt, deswegen liefs dort.Moral: Wenn nur irgendwie möglich FINGER WEG von char-Arrays und allem anderen was nicht über Längenchecks etc. verfügt.
-
Es sei denn, man weiß was man tut. Wenn man das sauber durchzieht und darauf achtet dass die Längen immer eingehalten werden, dann geht das auch.
Hab gerade letztens einen Server komplett in Ansi-C entwickelt... es geht wirklich wenn man aufpasst

-
pumuckl schrieb:
Tachyon schrieb:
Undefiniert heisst, es kann alles mögliche passieren...
Oft gesehen ist z.B. ein segmentation fault/violation. Das Programm schmiert dir dann ab, nachdem es eine entprechende Fehlermeldung in den Äther geschrien hat.
Ein anderes Problem hatte ich neulich: das Programm hat sich sang- und klanglos verabschiedet. Allerdings nur wenn man nicht im Debug-Modus kompiliert hat, denn im Debugmodus liefs ohne Probleme (!)
Die Funktion in der der Fehler passiert ist wurde (ohne Debugmodus) einwandfrei bis zum Ende ausgeführt (letzter Befehl war ein cout-statement), allerdings wurde der nächste Befehl nach der Funktion (auch ein cout statement) nie erreicht. Mit den Erkenntnissen hatte ein Kollege mir den Schlamassel übergeben.
Ergebnis: die Funktion wimmelte vor char-Arrays, printf()'s und all dem grausigen Geraffel ohne irgendwelche Längenchecks. An einer Stelle ging das dann auch schief, im Release-Modus wurde die Rücksprungadresse überschrieben, im Debug-Modus hats nur die Debuginformationen erwischt, deswegen liefs dort.Moral: Wenn nur irgendwie möglich FINGER WEG von char-Arrays und allem anderen was nicht über Längenchecks etc. verfügt.
std::cin.getlineHAT aber einen Längencheck. Nur sollte man da auch die richtige Länge einsetzen.
So könnte man auch argumentietren, dass man keine Iteratoren benutzen soll. Die haben auch keinen Längencheck.
Aber die Moral Deiner Aussage ist natürlich richtig: lieberstd::getlineundstd::stringbenutzen.