Warum setzt „stringstream >>' die Zielvariable bei einem Extraktionsfehler in C 11 und höher auf Null?

>` Zielvariable bei Extraktionsfehler in C 11 und höher auf Null setzen? " />

Warum ändert stringstream >> den Wert von Target bei einem Fehler?

In der zitierten Passage aus Stroustrups „TC PL, 3rd Edition“ gibt der Autor an, dass der Wert von v sollte unverändert bleiben, wenn die Extraktionsoperation fehlschlägt. Ein Beispiel widerspricht dieser Aussage, da v auf Null gesetzt wird, wenn die Stringstream-Operation >> schlägt fehl.

Erklärung des widersprüchlichen Verhaltens

Der Schlüssel zum Verständnis dieses scheinbaren Widerspruchs liegt im unterschiedlichen Verhalten des Extraktionsoperators >> vor und nach C 11.

Vor C 11

Prior Bis C 11 verwendete >> einen Analysemechanismus im Scanf-Stil. Wenn die Extraktion fehlschlug, wurde der Wert von v unverändert gelassen und das Failbit-Flag gesetzt.

Seit C 11

Mit C 11 wurde auf die Verwendung der Facette std::num_get zum Parsen der Eingabe umgestellt, wenn Extraktion schlägt fehl:

• Für Basistypen wie int wird 0 in v geschrieben und das Failbit-Flag gesetzt.
• Für Typen mit Überlaufschutz, wie std::numeric_limits:: max() oder std::numeric_limits::min() wird nach v geschrieben und das Failbit-Flag ist eingestellt.

Erklärung der Beispielausgabe

Im bereitgestellten Beispiel:

• Der Wert von v ist anfänglich 123.
• Nach dem Versuch, ein Wort in v einzulesen (was fehlschlägt), wird der Wert von v auf gesetzt 0.
• rdstate() des Stringstreams zeigt an, dass das Failbit gesetzt ist, was den Extraktionsfehler bestätigt.

Dieses Verhalten stimmt mit dem aktualisierten Verhalten von >> überein. eingeführt in C 11.

Das obige ist der detaillierte Inhalt vonWarum setzt „stringstream >>' die Zielvariable bei einem Extraktionsfehler in C 11 und höher auf Null?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!