Operator >> überladen



  • 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.



  • Wie bitte? oO


  • Mod

    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



  • 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.


  • Mod

    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.



  • 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.


  • Mod

    pyhax schrieb:

    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.

    Ich meinte eher ein echtes unerwünschtes Resultat, keine Theoretisierungen. Keine Maschinen auf der ganzen Welt, auch keine virtuelle Maschinen oder Maschinen die erst noch gebaut werden müssen, verhalten sich so.

    Sonst ist von nun an jeder Code, der sich auf ASCII kompatiblen Zeichensatz, zwölfmonatige Jahre oder eine funktionierende CPU verlässt falsch, da er unerwünschte Resultate erzeugen kann.



  • SeppJ schrieb:

    ...

    Und wenns sein muss, bau ich dir eine Maschine, die bei einem Overflow jedem Byte '=' zuweist. Deine Einstellung zum Thema Standard-konform ist dumm und naiv.


  • Mod

    314159265358979 schrieb:

    SeppJ schrieb:

    ...

    Und wenns sein muss, bau ich dir eine Maschine, die bei einem Overflow jedem Byte '=' zuweist.

    Quark, mal wieder, leider.

    314159265358979 schrieb:

    Dabei kann ein Überlauf auftreten, was zu implementation-defined behavior führt.

    SeppJ schrieb:

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

    Du gehst fälschlicherweise davon aus, als wäre meine Richtigstellung deiner Falschaussage auf meinen Code zutrifft. Tja, nur kann bei mir gar kein arithmetischer Überlauf stattfinden, außer sizeof(char) == sizeof(int). Das fange ich im configure ab, auf solchen Maschinen arbeite ich nicht. Ansonsten ist die Zuweisung von int an char implementation defined, damit kann ich und so ziemlich jeder Programmierer auf der Welt leben. Eine Implementierung die da was komisches definiert, unterstütze ich nicht.

    314159265358979 schrieb:

    Deine Einstellung zum Thema Standard-konform ist dumm und naiv

    Ist schon scheiße, wenn man (mal wieder) Unrecht hat und (mal wieder) anderen vorschnell Dummheit und Schlimmeres vorwirft. Dann steht man nämlich besonders lächerlich da und keiner mag einen. Aber so langsam solltest du dich dran gewöhnt haben.

    In 2-3 Jahren lernst du vielleicht auch mal genau nachzudenken, anstatt erstmal blöd zu melden.



  • SeppJ schrieb:

    Ist schon scheiße, wenn man (mal wieder) Unrecht hat und (mal wieder) anderen vorschnell Dummheit und Schlimmeres vorwirft. Dann steht man nämlich besonders lächerlich da und keiner mag einen. Aber so langsam solltest du dich dran gewöhnt haben.

    Du bist im Unrecht. Deine Aussage "wird nirgens so sein" ist einfach dummlicher Mist. Würde ich sowas von mir geben, dann würde man sofort wieder auf mich losgehen. Aber weiß du was: Sobald es um sowas geht, übernehme ich einfach deine Einstellung und zitiere dich bei Bedarf. Danke für die Freikarte.

    Und bevor du von deinem "Ich-mag-PI-nicht"-Thron nicht wieder runter kommst, diskutiere ich nicht mehr mit dir. Ich habs nicht nötig, mir von einem Mod ans Bein pissen zu lassen.



  • 314159265358979 schrieb:

    SeppJ schrieb:

    Ist schon scheiße, wenn man (mal wieder) Unrecht hat und (mal wieder) anderen vorschnell Dummheit und Schlimmeres vorwirft. Dann steht man nämlich besonders lächerlich da und keiner mag einen. Aber so langsam solltest du dich dran gewöhnt haben.

    Du bist im Unrecht.

    Nope. SeppJ hat Recht.
    Er hat meistens Recht.


  • Mod

    314159265358979 schrieb:

    Deine Aussage "wird nirgens so sein" ist einfach dummlicher Mist.

    Quark, mal wieder, leider.

    Es ist nirgendwo so. Es ist mir sogar vom Standard garantiert, dass dieses Verhalten dokumentiert werden müsste und nicht undefiniert ist. Irgendwo weiter vorne im Code ist noch ein static_assert, welches sizeof(int)>1 prüft.

    Ich habs nicht nötig, mir von einem Mod ans Bein pissen zu lassen.

    Du pisst jedem ans Bein. Daher hauen die Leute die hier länger mitlesen so gerne auf dich ein. Ich haue auch gerne wieder auf dich ein, wenn du mal ein Codebeispiel bringst, dessen Standardkonformität auch nur irgendwie im Zweifel ist. Aber da du fast nie hilfst, sondern bloß flamest, ist Code von dir ja eher selten.
    Hmm, ich habe eines:

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

    Hmm, was passiert wohl in einer freestanding Implementation? Compiliert nicht 👎 .

    Außerdem ist nicht garantiert, dass das basic source character set und das basic execution character set die gleichen Werte für '=' haben, es ist nur garantiert, das beide ein '=' enthalten. Man könnte eine Maschine bauen, bei der das nicht so ist. Standardkonform wäre es nur, wenn du im (implementation defined) basic execution character set die Nummer vom '=' raussuchst und direkt angibst oder die \u-Schreibweise benutzt (siehe unten). 👎

    Diese beiden Fehler möchte ich von dir nicht noch einmal sehen! Demnächst also alle chars als Hexnummern angeben (laut 2.2/2 garantiert, dass diese ISO 10646 entsprechen) und immer schön angeben, wenn deine Programme nur in einer hosted Implementation laufen. Sonst sind die ganzen Mikrocontrollerprogrammierer schwer enttäuscht von der Qualität deiner Beiträge und halten dich für dumm und naiv.



  • Du willst also Krieg. Kannst du haben.



  • SeppJ schrieb:

    Außerdem ist nicht garantiert, dass das basic source character set und das basic execution character set die gleichen Werte für '=' haben, es ist nur garantiert, das beide ein '=' enthalten.

    Kannst du das vielleicht nochmal kurz erläutern? Ich dachte bislang, dass der Compiler ein '=' immer in das basix execution character set transformieren müssen? sonst würden ja die ganzen Vergleiche der Art "x == '='" nicht garantiert funktionieren.

    Und wann währen die sets nicht gleich? Wäre das zum Beispiel der Fall, wenn ich auf meinem "normalen linux" einen gcc-crosscompiler auf $ABSTRUSE_PLATTFORM benutzen würde? Dann wäre mein source character set irgendwas ASCII compatibles und meine abstruse plattform irgendein microcontroller mit proprietärer Kodierung.


  • Mod

    otze schrieb:

    SeppJ schrieb:

    Außerdem ist nicht garantiert, dass das basic source character set und das basic execution character set die gleichen Werte für '=' haben, es ist nur garantiert, das beide ein '=' enthalten.

    Kannst du das vielleicht nochmal kurz erläutern? Ich dachte bislang, dass der Compiler ein '=' immer in das basix execution character set transformieren müssen? sonst würden ja die ganzen Vergleiche der Art "x == '='" nicht garantiert funktionieren.

    Also im Standard steht nur, dass das execution character set ein superset des basic character sets sein muss und dass für beide '0' + 1 == '1', usw. gilt. Aber von einer Übereinstimmung der tatsächlichen Werten konnte ich da nix finden.

    Und wann währen die sets nicht gleich? Wäre das zum Beispiel der Fall, wenn ich auf meinem "normalen linux" einen gcc-crosscompiler auf $ABSTRUSE_PLATTFORM benutzen würde? Dann wäre mein source character set irgendwas ASCII compatibles und meine abstruse plattform irgendein microcontroller mit proprietärer Kodierung.

    Wenn ich mit meinem ASCII-Computer ein Programm für einen EBCDIC-Rechner Cross-compiliere sollte das relevant werden. Ich vermute sogar, dass der Standard vielleicht sogar wegen dieser Konstellation so vage formuliert ist. Insofern hat das Beispiel sogar echte historische Relevanz und ist nicht so eine hirnverbrannte Behauptung wie, dass c + 1 unerwartete Resultate liefern könnte.

    314159265358979 schrieb:

    Du willst also Krieg. Kannst du haben.

    Junge, du bist mit jedem im Krieg. Ich bin vermutlich sogar der einzig verbliebene Mod, der dich noch nie gebannt hat, da ich es als eigene Schuld der Forenmitglieder ansehe, überhaupt mit dir zu reden.



  • SeppJ schrieb:

    314159265358979 schrieb:

    Du willst also Krieg. Kannst du haben.

    Junge, du bist mit jedem im Krieg.

    Jupp 🙂
    *Uzi auspack*



  • hustbaer schrieb:

    SeppJ schrieb:

    314159265358979 schrieb:

    Du willst also Krieg. Kannst du haben.

    Junge, du bist mit jedem im Krieg.

    Jupp 🙂
    *Uzi auspack*

    Römer gegen Römer, ja ist denn heut schon Weihnachten 🕶



  • Wie, Römer?
    Uzi kommen aus Israel.
    Aber gut, dann eben
    *Glock auspack*


Anmelden zum Antworten