T
unskilled schrieb:
@Ad aCTa: erwischt ^^
@tntnet: naja... ich würds so nciht machen : P
kürzer ist es nur, weil ich ne extra fkt gebaut hab und das nicht öffnen abfange(wieso auch immer, aber es kann ja ganz hilfreich sein, zu wissen, dass die datei nicht geöffnet wurde und nciht einfach nur leer ist)
2. wird dort imho auch im release hin- und her-kopiert...
da strings idR als vector (am stück-speicher) implementiert sind, heißt das also, dass du bei großen dateien 2x ganz viel speicher am stück brauchst - die wahrscheinlichkeit ist also wesentlich höher, dass bad_alloc fliegt...
bb
Klar kann ich nach dem anlegen des ifstreams abfragen, ob es geklappt hat. Fehlerprüfung habe ich der einfachheit halber mal weg gelassen.
Zu deinem 2. Punkt: Dein Code ist mindestens genauso ineffizient. Der istream_iterator ist kein random access iterator. Daher kann der string-Konstruktor nicht feststellen, wie viele Zeichen kommen. Er kann nur Zeichenweise vom Iterator lesen und in seinen Puffer übernehmen. Da muss er beim alloziieren raten, wie viele Zeichen noch kommen.
Bei meiner Methode kann der istream operator für streambuf wenigstens abfragen, wie viele Zeichen momentan im Puffer stehen und so die Zeichen blockweise lesen. Das kann performanter sein. Da gibt es ein wenig mehr Optimierungspotential für den Implementierer der Standardbibliothek.
Will man wirklich vermeiden, dass die Daten hin und her kopiert werden, muss man beispielsweise mit stat vorher die Dateigrösse abfragen und dann mit std::string::reserve den Speicher vorreservieren.
Im übrigen solltest Du Dir mal den streambuf_iterator anschauen. Der wäre für Deinen Fall ein wenig besser geeignet. Da entfällt dieses noskipws.
