stringstreams string to char number
-
Ich habe aber noch nie verstanden, wie man bei atoi() sinnvoll Fehler abfragt. Wie macht man das?
Die Fehlerbehandlung beschränkt sich bei atoi auf ein Checken nach 0 bzw INT_MAX / INT_MIN.
Naja, hängt vom Input ab. Wenn man weiß dass der Input möglicherweise fehlerhaft ist, würde ich auch boost::lexical_cast verwenden.
Stringstreams bringen halt ne Menge Overhead mit. Was mich dabei am meisten stört ist dass der String erstmal in den internen Buffer kopiert wird bzw der anglegt werden muss. Sollte eigentlich unproblematisch sein, eine Art stringstream zu bauen, der nicht buffert und nur einen Zeiger auf die Zeichenkette besitzt.
Geschätzt die Hälfte der Zeit ist bei meinem aktuellen Projekt die CPU beschäftigt zwischen Buffern hin- und herzukopieren bzw Speicher zu besorgen. Und das in 90% der Fälle grundlos, da meine Rohdaten sowieso die komplette Lebensdauer des stringstreams gültig sind bzw verändert werden dürfen ...
-
Wenn du mich fragst machst du was ganz grundlegend falsch wenn du ständig neue stringstreams erzeugen und wieder zerstören musst...
-
Naja, ich bekomme per Netzwerk permanent Strings rein, die geparsed werden müssen.
Heißt, als erstes buffert boost::asio sie zwischen, bevor sie in einem std::string wandern, der meinen Callbacks übergeben wird. Die Callbacks kopieren sie wiederrum in einen Stringstream um sie parsen zu können.Wenn ich sowohl den Code von Asio als auch von stringstream ändern könnte, würde einfach einen Vektor mit ausreichender Kapazität für die Strings reserviert werden, der direkt durch die entsprechende Input-Funktionen (hier wohl recv) befüllt werden würde und der stringstream würde das nicht auch nochmal kopieren.
-
Ethon schrieb:
Die Fehlerbehandlung beschränkt sich bei atoi auf ein Checken nach 0 bzw INT_MAX / INT_MIN.
Also keine Fehlerbehandlung. Das macht
atoi()nutzlos für alle Fälle, wo die Eingabe nicht garantiert im richtigen Format vorliegt. Unter anderem für alle Benutzereingaben...
-
Wieso gibt es hier immer wieder so simple Fragen, die mit der Standardlibrary stdlib von C ausreichend abgedeckt sind? Die Streamklassen von C++ dienen nur der unkomplizierten Ein- und Ausgabe.
Ich habe zunehmend Probleme, solche Fragen und die darauf gegebenen Antworten zu verstehen! 
-
Das Problem ist dass die C Standardlib für viele C++ler wohl tabu ist
Wenn man also nicht gleich ca. 100 flames kassieren möchte nutzt man in C++ Projekten am besten auch nur C++. Ob das jetzt gut oder schlecht ist dazu äußere ich mich mal nicht
-
Nein, C ist manchmal schon okay. Man muss sich einfach bewusst sein, dass man sehr schnell auf Einschränkungen und Probleme trifft, die man mit den C++-Äquivalenten nicht hat. Hier wäre das die Fehlerbehandlung, andernorts sind es Pufferüberläufe, manuelle Speicherverwaltung und generelles Rumgefrickel.
Performance kann im Falle der Streams tatsächlich ein Grund für C sein, falls sie wirklich benötigt wird. Wenn es aber um Zeichenketten und Container geht, ist dieses Argument aber schnell einmal nicht mehr gegeben. Lustigerweise ist C++ in diesem Bereich sogar eher schneller
Und dann gibt es Dinge wie
<cmath>, gegen die hat keiner etwas. Man muss nicht gleich alles in eine Schublade stecken...
-
Wie gesagt - viele - nicht alle
Und ob jetzt niemand etwas gegen <cmath> hat kann ich nicht wirklich sagenKleine Anmerkung @berniebutt
Geschwindigkeit war für mich kein wirklicher Aspekt - ich versuche nur mich etwas weiter in C++ reinzudenken und dazu gehört nunmal auch die "C++-Variante" von atoi oder sonstwas zu kennen
-
cooky451 schrieb:
Kleine Anmerkung @berniebutt
Geschwindigkeit war für mich kein wirklicher Aspekt - ich versuche nur mich etwas weiter in C++ reinzudenken und dazu gehört nunmal auch die "C++-Variante" von atoi oder sonstwas zu kennenIst ok, kennen sollte man das schon. Gerade für kleine strings reichen die C-Methoden aber oft völlig aus, auch für deren Umwandlungen wie atoi oder itoa. Wer denkt da gleich an Performanceunterschiede? Aber - wie gesagt - es gibt viele C++ Puristen hier, für die reines C etwas unüblich gewordenes aus der Steinzeit ist. Diese Leute kennen auch nicht die Anfänge der PC-Programmierung, wo man oft notwendig OBJ-Files verschiedener Compiler wie FORTRAN, C, ASM, ... lustig miteinander gelinkt hatte.
Ich hoffe, du kannst deine Frage jetzt selbst beantworten! Es liegt mir fern, deinen Ehrgeiz zum Hinzulernen bremsen zu wollen. Was du dann wo und wie machst bleibt allein deine Sache!
Hauptsache es läuft sicher und stabil oder wenn nicht findest du schnell die Ursache und kannst sie mühelos bereinigen.
-
berniebutt schrieb:
Aber - wie gesagt - es gibt viele C++ Puristen hier, für die reines C etwas unüblich gewordenes aus der Steinzeit ist. Diese Leute kennen auch nicht die Anfänge der PC-Programmierung, wo man oft notwendig OBJ-Files verschiedener Compiler wie FORTRAN, C, ASM, ... lustig miteinander gelinkt hatte.
Das sind lediglich Geschichten die sich manche die C++ noch nicht ganz verstanden haben gern ausmalen
itoa() ist übrigens keine Standardfunktion.
-
dot schrieb:
Das sind lediglich Geschichten die sich manche die C++ noch nicht ganz verstanden haben gern ausmalen
itoa() ist übrigens keine Standardfunktion.WOW, was für ein Vortrag voller Kompetenz, Erfahrung und praktischem Wissen!
-
berniebutt schrieb:
WOW, was für ein Vortrag voller Kompetenz, Erfahrung und praktischem Wissen!
Sagt einer, der sich für C ausspricht mit der Begründung, man hätte das in den Anfängen der Programmierung so gemacht.
-
Nexus schrieb:
berniebutt schrieb:
WOW, was für ein Vortrag voller Kompetenz, Erfahrung und praktischem Wissen!
Sagt einer, der sich für C ausspricht mit der Begründung, man hätte das in den Anfängen der Programmierung so gemacht.
Dann wären aber Lochkarten angebrachter..
