Probleme bei Stringbearbeitung

SeppJ schrieb:

bei der du nur irgendein Beispiel hättest konstruieren brauchen (imho unmöglich, aber wer weiß), um mich zu demütigen

Du persönlich bist mir egal. Ich will die Iostreams demütigen.

Fuchs aus dem Wald

eSsThehelL schrieb:

Du persönlich bist mir egal. Ich will die Iostreams demütigen.

Na dann auf!

SeppJ

eSsThehelL schrieb:

SeppJ schrieb:

Ich warte immer noch auf eine gleichwertige Implementierung deinerseits, die formatiert aus Iteratorquellen lesen kann.

Kannst du konkret sagen, wo das im ersten Beispiel nicht der Fall ist?

An der Stelle an der du einfach Zeichen weiter drückst, ohne auf jedwedes Format zu achten? Es geht bei dem Code nicht darum, Iteratoren zu dereferenzieren und irgendwo hin zu schreiben (Das könnte man auch und man braucht das bei weitem nicht so umständlich wie du zu machen). Es geht darum, dass man Iteratoren->Stream umwandeln kann, so dass man all die tollen Sachen machen kann, die man nur mit Streams machen kann (zum Beispiel Interpretation formatierter Daten), ohne das man jemals Kopien oder gar Mehrfachiteration benötigt (Skym0sh0 auf Seite 1).

Deine Alternativvorschläge können genau diese Kernpunkte nicht erfüllen. Sie können nicht formatiert lesen und dein Rettungsversuch (strtoi) benötigt wieder Kopien (wie bekommst du die Daten in strtoi?) und eventuell sogar Mehrfachiteration (wie trennst du die Tokens?).

Hier ein konkretes Beispiel:

{
    std::forward_list<int> foo = {52, 32, 56, 32, 49, 53, 32, 49, 54, 32, 50, 51, 32, 52, 50};
    iterator_streambuf<decltype(foo.begin())> buf(foo.begin(), foo.end());
    std::istream in(&buf);

    int sum = 0;
    for(int i; in >> i; sum += i);  
    std::cout << sum << '\n';
  }

Mach mal nach. Wenn du das schaffst, dann zeige ich dir auch irgendwann mal get, read & Co, damit du aus Streams unformatiert lesen kannst, ohne istreambuf_iterator-Monstren zu benutzen . (Du wirst bei letzterem feststellen, dass mein streambuf bloß ein dünner Abstraktionslayer um die Iteratoren ist, so dass diese Aktionen ungefähr genau so schnell wie eine Schleife über die Iteratoren sind. Erst recht, wenn man das noch fehlende xsgetn
mit Zusatzinformationen über den Iteratortyp implementiert.)

SeppJ schrieb:

Es geht darum, dass man Iteratoren->Stream umwandeln kann, so dass man all die tollen Sachen machen kann, die man nur mit Streams machen kann (zum Beispiel Interpretation formatierter Daten)

Die "tollen Sachen" sind ziemlich genau auf

Whitespace-getrennten-Standarddatentypen-Input

beschränkt.

Es ist für mich kein Wunder, dass du dich mit deinen Beispielen auf Ints mit Leerzeichen dazwischen beschränkst und dich weigerst, die Aufgabe von freakC++ zu lösen. Vielleicht ist die Schlussfolgerung falsch, aber mit deinem Verhalten bestätigst du mir das nur.

SeppJ schrieb:

ohne das man jemals Kopien oder gar Mehrfachiteration benötigt (Skym0sh0 auf Seite 1).

Iteratoren sind nicht deshalb schlecht, weil sie jemand falsch verwendet. Trotzdem, ich bin fast sicher, dass der schlechte Code von Skym0sh0 schneller als deiner ist, du deinen mit Tuning aber schneller machen könntest.

SeppJ schrieb:

Deine Alternativvorschläge können genau diese Kernpunkte nicht erfüllen. Sie können nicht formatiert lesen und dein Rettungsversuch (strtoi) benötigt wieder Kopien (wie bekommst du die Daten in strtoi?) und eventuell sogar Mehrfachiteration (wie trennst du die Tokens?).

Mehrfachiteration brauchen nur die Streams, weil die grundlos einen internen Buffer halten. Mit Streams hast du im prinzip einen limitierten Inputiterator, sobald du für etwas Mehrfachiteration brauchst, muss das jedesmal gecached werden.

SeppJ schrieb:

Hier ein konkretes Beispiel:

Wo ist der Erkenntnisgewinn?

auto& ct = std::use_facet<std::ctype<char>>(std::locale());
int sum = 0;
for (auto it=foo.begin(), end=foo.end(); it != end;)
  sum += parse<int>(it, end, it, ct);
std::cout << sum << '\n';

// wobei
template <typename T, typename In, typename Facet>
T parse(In from, In to, In& next, Facet& ct, int base=10)
{
  // Facet nur um SeppJ zufriedenzustellen ("formatiert")                                  
  auto nospace = [&ct](char c){return !ct.is(std::ctype_base::space, c);};
  auto isdigit = [&ct](char c){return ct.is(std::ctype_base::digit, c);};
  std::string buf; char *p;
  next=copy_until(std::find_if(from,to,nospace),to,std::back_inserter(buf),isdigit);
  T t = strtol(buf.c_str(), &p, base);
  if (p == buf.c_str()) throw std::invalid_argument("");
  return t;
}

Das ist genau das gleiche wie das mit Strings, nur dass leider keine parse-Funktion für Iteratoren gibt.

Davon abgesehen ist der Code immer noch um Faktor 5 schneller als deiner mit den Streams. Ein Aufruf einer virtuellen Funktion macht das kopieren eines chars wett.

SeppJ schrieb:

Wenn du das schaffst, dann zeige ich dir auch irgendwann mal get, read & Co, damit du aus Streams unformatiert lesen kannst, ohne istreambuf_iterator-Monstren zu benutzen .

Zeig mal. Meine Beispiele hast du ja.

SeppJ schrieb:

(Du wirst bei letzterem feststellen, dass mein streambuf bloß ein dünner Abstraktionslayer um die Iteratoren ist

lol. Ja, dein streambuf schon. Aber das ganze drumherum ist alles andere als dünn.

SeppJ

eSsThehelL schrieb:

Es ist für mich kein Wunder, dass du dich mit deinen Beispielen auf Ints mit Leerzeichen dazwischen beschränkst

Um die Beispiele einfach zu halten . Ich kann auch gerne einen selbstdefinierten operator>> nehmen. Bin mal gespannt, wie du damit zurecht kämst.

und dich weigerst, die Aufgabe von freakC++ zu lösen.

Aufmerksamer Leser

FreakC++: Ich will A
Skym0sh0: Hier eine Lösung L(A) für A
SeppJ: Das geht besser. Hier eine Lösung L2(A) für A. Die ist dafür superplusgut.
FreakC++: Ich will aber B
knivil, SeppJ und andere: Dafür nimmt man L(B). Das ist dafür superplusgut.

Du: SeppJ, dein L2(A) geht nicht auf B! Du bist doof! Wähwähwäh! qq! Wenn du B nicht mit L2(A) löst, dann geh ich zu meiner Mama!

SeppJ schrieb:

ohne das man jemals Kopien oder gar Mehrfachiteration benötigt (Skym0sh0 auf Seite 1).

Iteratoren sind nicht deshalb schlecht, weil sie jemand falsch verwendet. Trotzdem, ich bin fast sicher, dass der schlechte Code von Skym0sh0 schneller als deiner ist, du deinen mit Tuning aber schneller machen könntest.

Nein, ist er nicht.

SeppJ schrieb:

Hier ein konkretes Beispiel:

Wo ist der Erkenntnisgewinn?

Du könntest etwas lernen. Aber ja, diese Hoffnung besteht nicht wirklich.

Das ist genau das gleiche wie das mit Strings, nur dass leider keine parse-Funktion für Iteratoren gibt.

Ach! Man könnte meinen, dass dies the whole fucking point war! Was soll man danach noch sagen? Doppeldenk?