Operator >> überladen

SeppJ

Ethon schrieb:

Dann änder das Format in "Key = Value;" und SeppJ ist zufrieden, ohne dass du eine einzige zusätzliche Zeile Code schreiben musst.

314159265358979

Hm. Klingt gar nicht mal so blöd.

while(is >> key >> Char<'='> >> value >> Char<';'>)
    ...

314159265358979 schrieb:

Char<'='>

Wasn das?

SeppJ

Hacker schrieb:

Wasn das?

Ich vermute mal aus dem Zusammenhang etwas wie:

template <char C> struct Char
{
  friend istream& operator>>(istream & in, Char)
  {
    char c = C + 1;
    in >> c;
    if (c != C)
      in.setstate(ios::failbit);
    return in;
  }
};

SeppJ schrieb:

Hacker schrieb:

Wasn das?

Ich vermute mal aus dem Zusammenhang etwas wie:

template <char C> struct Char
{
  friend istream& operator>>(istream & in, Char)
  {
    char c = C + 1;
    in >> c;
    if (c != C)
      in.setstate(ios::failbit);
    return in;
  }
};

Wieso C + 1 ?

SeppJ

Hacker schrieb:

Wieso C + 1 ?

Damit c auf jeden Fall ungleich C ist.

Außerdem ist natürlich die Operatorüberladung als friend bei einem memberlosen struct etwas sinnlos, das war ~~Gewohnheit~~ eine ganz clevere Optimierung der Compilezeit, damit mit weniger mögliche Überladungen im globalen Namensraum liegen .

SeppJ schrieb:

Hacker schrieb:

Wieso C + 1 ?

Damit c auf jeden Fall ungleich C ist.

Da hat mein Gehirn mal wieder kurz eine Auszeit genommen. Natürlich, jetzt ergibt das viel Sinn

314159265358979

SeppJ schrieb:

Damit c auf jeden Fall ungleich C ist.

Dabei kann ein Überlauf auftreten, was zu implementation-defined behavior führt. Desweiteren habe ich zum Verstehen des Codes nun eine Minute länger gebraucht.

Warum diesen "Hack" verwenden, wenn du auch einfach if(is >> c && c != C) schreiben könntest? Premature und so :p

Übrigens wäre Char ein Funktionstemplate, kein Klassentemplate.

Ethon

314159265358979 schrieb:

SeppJ schrieb:

Damit c auf jeden Fall ungleich C ist.

Dabei kann ein Überlauf auftreten, was zu implementation-defined behavior führt. Desweiteren habe ich zum Verstehen des Codes nun eine Minute länger gebraucht.

Warum diesen "Hack" verwenden, wenn du auch einfach if(is >> c && c != C) schreiben könntest? Premature und so :p

Übrigens wäre Char ein Funktionstemplate, kein Klassentemplate.

Das ist kein Hack, stinknormale Vorgehensweise, wenn du einen Integer möchtest, der garantiert ungleich einem Anderen ist.
Wird sehr oft bei Prüfsummen etc eingesetzt, um garantiert falsche Prüfsummen zu erzeugen.

SeppJ

314159265358979 schrieb:

SeppJ schrieb:

Damit c auf jeden Fall ungleich C ist.

Dabei kann ein Überlauf auftreten, was zu implementation-defined behavior führt. Desweiteren habe ich zum Verstehen des Codes nun eine Minute länger gebraucht.

Warum diesen "Hack" verwenden, wenn du auch einfach if(is >> c && c != C) schreiben könntest? Premature und so :p

Übrigens wäre Char ein Funktionstemplate, kein Klassentemplate.

Dann hätte ich aber eine Minute länger gebraucht, um den Code zu entwickeln. Das war bloß ein schneller Hack, um Hacker zu erklären, was das ungefähr ist, was du da meinst.

(signed) Überlauf ist übrigens gänzlich undefined.

SeppJ schrieb:

314159265358979 schrieb:

SeppJ schrieb:

Damit c auf jeden Fall ungleich C ist.

Dabei kann ein Überlauf auftreten, was zu implementation-defined behavior führt. Desweiteren habe ich zum Verstehen des Codes nun eine Minute länger gebraucht.

Warum diesen "Hack" verwenden, wenn du auch einfach if(is >> c && c != C) schreiben könntest? Premature und so :p

Übrigens wäre Char ein Funktionstemplate, kein Klassentemplate.

Dann hätte ich aber eine Minute länger gebraucht, um den Code zu entwickeln. Das war bloß ein schneller Hack, um Hacker zu erklären, was das ungefähr ist, was du da meinst.

Was das war, habe ich in der ersten Sekunde erkannt, ich wollte nur wissen ob das irgendwie in der Standardbibliothek vorkommt (vielleicht C++11-bezogen oder so ^^). War anscheinend eine PI-Exotik.

314159265358979

SeppJ schrieb:

Dann hätte ich aber eine Minute länger gebraucht, um den Code zu entwickeln.

Soll das ein Witz sein?

SeppJ schrieb:

Das war bloß ein schneller Hack, um Hacker zu erklären, was das ungefähr ist, was du da meinst.

Und wie man an Hackers Nachfrage erkennt, ist er zum Erklären ungeeignet. Zumindest ein Kommentar hätte da hingehört, wenn du es nicht "ordentlich" machst.

SeppJ schrieb:

(signed) Überlauf ist übrigens gänzlich undefined.

Das ist mir wiederum neu.

314159265358979 schrieb:

Und wie man an Hackers Nachfrage erkennt, ist er zum Erklären ungeeignet.

Und wie man an deiner "Meinung" erkennt, liegt deine soziale Kompetenz mal wieder irgendwo bei 0.

314159265358979

Wie bitte? oO

SeppJ

314159265358979 schrieb:

SeppJ schrieb:

Dann hätte ich aber eine Minute länger gebraucht, um den Code zu entwickeln.

Soll das ein Witz sein?

Wie soll ich deine Konstrukte aus dem Handgelenk 1:1 reproduzieren?

SeppJ schrieb:

Das war bloß ein schneller Hack, um Hacker zu erklären, was das ungefähr ist, was du da meinst.

Und wie man an Hackers Nachfrage erkennt, ist er zum Erklären ungeeignet. Zumindest ein Kommentar hätte da hingehört, wenn du es nicht "ordentlich" machst.

Deswegen ist auch ein entsprechender Kommentar dabei . Außerdem ist das ordentlich und eine Standardvorgehensweise (wie dir Ethon erklärt hat). Es ist bloß nicht 1:1 wie du es bei dir hast. Und das ist in der Regel sogar ein gutes Zeichen.

Das ist mir wiederum neu.

Und du wunderst dich ernsthaft noch, wieso du mit der Kombination aus Unwissenheit und "ich habe immer auf jeden Fall Recht" so unbeliebt bist?

Edit: Einen weiter unten.

STOOOOOOPPP!!!! Du meintest der Hack ist zum erklären ungeeignet? Gott bin ich bescheuert

314159265358979

SeppJ schrieb:

Wie soll ich deine Konstrukte aus dem Handgelenk 1:1 reproduzieren?

Du weißt offenbar ganz genau, was ich damit meine, sonst hättest du es nciht reproduzieren können. Deine Implementierung ist nur hässlich.

SeppJ schrieb:

Deswegen ist auch ein entsprechender Kommentar dabei .

Da ist überhaupt kein Kommentar dabei. Erst nachdem Hacker nachgefragt hat, hast du dir die 2 Minuten (höhö) genommen, ihm zu erklären. Das hättest du dir gespart, wenn du es direkt für einen normalsterblichen Programmierer geschrieben hättest, oder zumindest einen Kommentar hinterlassen hättest.

SeppJ schrieb:

Außerdem ist das ordentlich

Unleserlicher Code ist grundsätzlich nicht ordentlich.

SeppJ schrieb:

und eine Standardvorgehensweise (wie dir Ethon erklärt hat).

Das bezweifle ich mal Stark. Man hätte es dann schließlich sicherlich schon gesehen.

SeppJ schrieb:

Es ist bloß nicht 1:1 wie du es bei dir hast.

Das ist wohl auch eher schwer möglich.

SeppJ schrieb:

Und das ist in der Regel sogar ein gutes Zeichen.

Im Gegensatz zu vielem anderen Code (Merke: Ich spreche hier explizit nicht von deinem), ist meiner i.d.R. sehr konsistent und übersichtlich. Und dadurch auch weitestgehend bugfrei.

SeppJ schrieb:

Und du wunderst dich ernsthaft noch, wieso du mit der Kombination aus Unwissenheit und "ich habe immer auf jeden Fall Recht" so unbeliebt bist?

Ob ich mit "implementation-defined" falsch liege und das nun undefined ist, ist wohl wirklich für die Meinung über mich egal. In beiden Fällen ist dein Code Mist, weil er unerwünschte Resultate erzeugen kann.

SeppJ

Man hätte es dann schließlich sicherlich schon gesehen.

Du bist nicht "man". Du bist sogar ziemlich unerfahren was Code außer deinem eigenen angeht.

314159265358979 schrieb:

. In beiden Fällen ist dein Code Mist, weil er unerwünschte Resultate erzeugen kann.

Nenn mir eines. Ansonsten laberst du Quark, mal wieder, leider.

pyhax

314159265358979 schrieb:

. In beiden Fällen ist dein Code Mist, weil er unerwünschte Resultate erzeugen kann.

Nenn mir eines.

Da signed integer overflow undefiniert ist, kann es dann nicht sein das nach c=C+1, wenn C+1 einen overflow erzeugt, in c wieder C steht (zufällig)? Und danach das cin>>c scheitert, was aber nicht erkannt wird.

Operator &gt;&gt; überladen

Operator >> überladen