C ist feindselig

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Natürlich wird gewandelt:

    Die Operation lautet: Teile Int(a) durch Int(b).
    Wenn du das jetzt mal auf Maschinenbefehle abbildest, wird das alles als Integer realisiert., das Ergebnis ist dann wieder ein Register/Speicherinhalt mit dem Typ "Int".

    Ggf. brauche ich dann noch den Restwert (mod)...

    Die Ausgabe mit echo erfolgt jedoch als Fließkommazahl... und das ist eine überraschende Type-Konvertierung.
    Ob da jetzt echo die Konvertierung vollzieht oder das schon das Ergebnis der Division ist, ist Wumpe...

    Das hat mit C-Tellerrand nichts zu tun, das hat was mit Typsicherheit zu tun:
    Der Entwickler hat einen Typ definiert und will nicht immer überlegen müssen, was der Compiler jetzt aus dem Ergebnis wohl machen wird... (Wir hatten das Problem ja schon mal weiter oben angesprochen - da war es jedoch klar)
    - wo da der Fortschritt steckt?

    Und mal ehrlich: Wenn der Parser im Compiler zwei verschiedene Divisionsoperanten benötigt (einmal für reine Integeroperationen und dann eine für Fließkomma) dann ist das _kein_ Fortschritt.

    Das das bei 30 Jahre alten Interpretern so war, ist mir sowas von...
    Hört sich an wie das alte Beamtenmantra:

    • "Das haben wir schon immer so gemacht"
    • "Das haben wir noch nie so gemacht"
    • "Da könnte ja jeder kommen"


    :lol:

  • Implizite Konversion ist praktisch aber hat manchmal unangenehme Nebeneffekte. Deshalb ist explizite Konversion sicherer.
    Aber auch C macht da noch implizite Konversion :shy: :

    waehrend go explizite Konversion verlangt:

    Dazu steht dann hier u.A.:

    Zitat von "golang-constants"


    This strictness eliminates a common cause of bugs and other failures. It is a vital property of Go. But it has a cost: it sometimes requires programmers to decorate their code with clumsy numeric conversions to express their meaning clearly.

  • Zitat von "Zentris" pid='294227' dateline='1502022233'

    Der Entwickler hat einen Typ definiert und will nicht immer überlegen müssen, was der Compiler jetzt aus dem Ergebnis wohl machen wird...

    Wo ist Dein Problem? Wenn Du einen Int haben willst, nimm halt div. Ist doch ganz klar definiert und in Verbindung mit mod verständlich.

    Im Gegenteil muss der Programmierer bei reinen Int-Divisionen eher überlegen, was er tut. Denn je nach Formel kommt da ganz schnell was ganz anderes raus.

    a = 50
    b = 50
    c = 3
    d = c / a * b
    e = c * b / a

    Mathematisch das Gleiche, in Pascal bekommt Du beide Male 3 heraus, in C einmal 0 und einmal 3. Und das Schlimmste in C - wenn es dem Compiler passt und er die Formel anders zusammenfasst, bekommst Du auch für d unterschiedliche Ergebnisse. Was ich da schon gesehen habe...

  • Zitat von "Timm Thaler" pid='294249' dateline='1502031525'

    Wo ist Dein Problem? Wenn Du einen Int haben willst, nimm halt div. Ist doch ganz klar definiert und in Verbindung mit mod verständlich.

    Ich hatte u.a. auch geschrieben:

    Zitat

    Und mal ehrlich: Wenn der Parser im Compiler zwei verschiedene Divisionsoperanten benötigt (einmal für reine Integeroperationen und dann eine für Fließkomma) dann ist das _kein_ Fortschritt.

    Das sagt wohl alles...
    Bei einigen Sprachen (z.B. PERL) gibt es auch noch unterschiedliche Vergleichsoperatoren (Numerisch/String). :wallbash:

    Wenn ich int haben will, dann verwende ich als Variablenwerte int. Was ist da für einen Parser nicht verständlich, den entsprechenden Operationstyp zu verwenden?
    Ich habe zwar noch nie einen Parser für Programmiersprachen geschrieben, aber andere Sprachen (z.B. Java) schaffen das ja offensichtlich.

    Es gibt natürlich einen "Seiteneffekt": Werden z.B. ein int und ein float miteinander verknüpft, was soll er nehmen?
    Hier sollte lautet die in in Java verwendete Regel: Der Typ des 1. Operators. Wenn man das nicht will, muss man casten.
    Diese Regel ist transparent, verständlich und reproduzierbar.

    Zitat von "Timm Thaler" pid='294249' dateline='1502031525'


    Im Gegenteil muss der Programmierer bei reinen Int-Divisionen eher überlegen, was er tut. Denn je nach Formel kommt da ganz schnell was ganz anderes raus.

    ...

    Mathematisch das Gleiche, in Pascal bekommt Du beide Male 3 heraus, in C einmal 0 und einmal 3. Und das Schlimmste in C - wenn es dem Compiler passt und er die Formel anders zusammenfasst, bekommst Du auch für d unterschiedliche Ergebnisse. Was ich da schon gesehen habe...

    Da z.B. in C/C++ (und auch in anderen Compilern) per Definition nicht definiert ist, in welcher Reihenfolge die Operationen durch den Compiler umgesetzt werden (Optimierungsproblematik), kommt es zu solchen "Effekten".

    Ist bei Fließkommaoperationen übrigens genau so: Da kann es aufgrund von Über/Unterläufen von Zwischenwerten ebenfalls zu falschen Ergebnissen kommen.

    Da hilft nur klammern: Ich setze aus genau diesem Grund lieber 2 Klammer zuviel als mich dann mit solchen Effekten herum zu schlagen und den Fehler zu suchen...

    ... und das wäre ja z.B. etwas, was die "Newcomersprachen" besser machen könnten... Tun sie das?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!