hustbaer schrieb:
Dravere schrieb:
hustbaer schrieb:
Die Optimierung über T& ist zwar grundsätzlich nett, in diesem Fall aber IMO etwas deplaziert.
Was genau meinst du damit?
* IMO müsste hier die NRVO greifen.
* Wenn's die nicht packt, dann Move-Semantik (aktuellen Compiler + Std. Library vorausgesetzt).
* Was liest man aus .ini Files, was mit einem stringstream/lexical_cast konvertiert werden müsste? Fallen mir jetzt nur Typen ein die wahnsinnig billig zu kopieren sind (Integers & Floats). Bleiben noch Strings, aber die müsste man nicht konvertieren. Eine Spezialisierung für std::
(w)string würde hier wesentlich mehr bringen als eine Variante mit Output-Parameter.
* Ich würde eine Funktion zum Lesen von Konfigurationsdaten nicht besonders optimieren. Zumindest nicht bevor mir mein Profiler sagt dass ich es tun sollte.
* Wenn man die Funktion wirklich unbedingt optimieren will, dann sollte man IMO den stringstream eliminieren. Was zugegebenermassen viel Arbeit ist. Die ich mir wie schon gesagt nicht antun würde, weil ich so eine Funktion gar nicht optimieren würde
Verstehe ich dich richtig, dass du damit meinst, dass man die ganze Funktion weglassen soll, welche einen dritten Parameter T& hat? Das war mir nämlich noch nicht so ganz klar, ob du meinst, ob man die Funktion weglassen soll oder nur die Referenz entfernen sollte.
Ich habe jedenfalls diese Funktion nicht hingeschrieben, weil ich an irgendeine Optimierung dachte, sondern an nicht triviale Konstruktoren. Ich muss dir aber zustimmen, dass die Chance für solche Typen eher sehr gering ist
pumuckl schrieb:
die haben die meisten (oder alle) header lesbar im Netz
Ok, ok, ich gebe ja zu, ich war nur zu faul
Sie machen es übrigens einfach mit einem zusätzlichen get danach und Überprüfung auf EOF .
typedef std::istringstream input_stream;
typedef input_stream::traits_type input_traits;
std::istringstream iss;
if(iss >> result && iss.get() == input_traits.eof())
{
// Erfolg!
}
Der Fehler oben war übrigens, dass ich gcount verwendet habe, zum Überprüfen einer formatierten Eingabe. gcount liefert aber nur die Menge der gelesenen Zeichen der letzten unformatierten Eingabe.
otze schrieb:
pumuckl schrieb:
http://www.boost.org/doc/libs/1_43_0/boost/lexical_cast.hpp
Das ist ein Witz, oder?
Ad aCTa schrieb:
1213 Zeilen Code für lexikalische Konvertierung? Das kann ich auch nicht nachvollziehen. Mit std::stringstream ist das ein 3-Zeiler?!
Schaut euch mal den Code genauer an, statt nur die Anzahl Zeilen zu zählen. Ihr könnt auch gerne mal mit einem Profiler die Geschwindigkeit des 3-Zeilers in einer Funktion mit dem boost::lexical_cast vergleichen. Ich würde mal behaupten aus längst vergangenen Messungen, dass boost::lexical_cast ca. 4 mal schneller ist. Die haben zahlreiche Optimierungen vorgenommen. Wenn man sogar genau hinschaut, so wird bei Standardtypen (double, float, int, usw.) kein std::stringstream verwendet. Nicht mal irgendein IOStream aus der Standardbibliothek, sondern es werden eigene "Streams" verwendet. Der Trick ist, dass für diese Typen die maximale Grösse als Strings ausgerechnet wird und zwar zur Kompilezeit. Danach wird Speicher dafür auf dem Stack geholt und in diesen Speicher dann geschrieben. Somit musste auch eigener Code her, welcher mit dem aktuellen std::local die Zahlen formatiert oder entsprechend einliest
Und beim Cast in einen std::string , da wird dann zum Beispiel gleich der Puffer des std::string genommen, statt noch über einen anderen Puffer zu gehen. usw. usf. Lest euch selber in den Code ein
Grüssli
PS: @Nexus, kann doch nix dafür, wenn der Standard mir das vorschreibt ...
