Ich habe hier gerade ein (für mich) unerklärbares phänomen:

typedef std::istreambuf_iterator<char, std::char_traits<char> > Iter;
void doSomeStuff( Iter beg, Iter end )
{
	string strDay( beg, end);//hier steht alles richtig drin -> will ich aber eigentlich nicht
	char C = *(beg);//liefert aber blödsin strDay[0] != C
	Iter itDot = find( beg, end, '.' );//liefert auch Blödsin -> ItDot = end
}

Ich will gerne das copieren bei der Konstruktion von strDay sparen und direkt mit den istreambuf_iterator-en arbeiten.

-> hab gerade nochmal gecheckt und den "Fehler" gefunden: wenn ich

string strDay( beg, end);

weglasse funktioniert es. Auch wenn ich in der main nach dem Aufruf von doSomeStuff versuche mit den iteratoren weiterzuarbeiten funktioniert nichts mehr. Werden die iteratoren, bei dem Konstruktoraufruf verändert, oder woran liegt das?
Ein typisches Beispiel, wie einem Kontrollausgaben, die man zum Debuggen einbaut auf die Füße fallen können :).

Viele Grüße,

Tobias

-3- [Note: For input iterators, a == b does not imply ++a == ++b. (Equality does not guarantee the substitution property or referential transparency.) Algorithms on input iterators should never attempt to pass through the same iterator twice. They should be single pass algorithms. Value type T is not required to be an Assignable type (lib.container.requirements). These algorithms can be used with istreams as the source of the input data through the istream_iterator class. ]

Wie wäre da jetzt ein elegantes vorgehen? (Das hängt Dicht mit meinem Internazionlisation Thread zusammen.)
Ich überschreibe gerde von meiner time_get facete die einzelnen Funktionen. Dort parse ich den inputstream z.b.nach dem beim deutschen Datum üblichen Punkt. Leider fällt dann die Verwendung von find aus, da das ja die Position des Iterators verändert.
Also giebt es IMO nur die Möglichkeit selber durch den stream zu laufen und dabei zu parsen, weil alles ander die iteratoren verändert bzw. inkrementiert.