3. Warum 1.f?

Warum 1.f?

  • ?

    Sind in C überhaupt Überladungen möglich?

    0
  • X

    Für mich wäre schon 1 Assembler-anweisung mehr Grund zum *f stil zu wechseln. Ich finde allerdings das

    int foo = 1;
bar(foo);

    lesbarer ist als

    int foo = 1;
bar(float(foo));

    um die Beispiele auf Variablen auszudehnen (da ist dann schon mehr schreibarbeit als nur ein extra Zeichen vonnöten.

    0
  • A

    Komisch, wo manche Leute versuchen wollen, Performance raus zu holen. 🙄
    80% der Laufzeit werden von 20% des Codes benutzt.

    Edit: Wieso sollte man explizit konvertieren? Das ist jetzt wirklich nicht notwendig.

    0
  • X

    @hmmmmmm: nein
    @Ad aCTa: ich wills nur "richtig" machen

    0
  • U

    x4rd3n schrieb:

    @hmmmmmm: nein
    @Ad aCTa: ich wills nur "richtig" machen

    man sollte dem compiler eigtl keine einzige konvertierungen überlassen - nicht weil er dumm wäre, sondern weil es eine potentielle fehlerquelle ist...
    ne gleitkommazahl ist nun mal nicht so genau wie ne ganzzahl und ne ganzzahl kann nun mal auch nur ganze zahlen darstellen. das ist auch der grund, warum dich der compiler(zumindest der msvc) bei fast jeder konvertierung warnt - weil es ab und an ja wirklich ungewollt ist und böse(kleinerer wertebereich -> zahl wird abgeschnitten) folgen haben kann...
    und ob ich nun foo(1) oder foo(1.f) schreibe sollte vom schreibaufwand ja völlig egal sein - es sei denn, dich bremst beim programmieren wirklich deine tippgeschwindigkeit...

    nötig sollte es weder in C noch in C++ sein, aber nicht nötig heißt nicht zwangsläufig immer, dass es gut ist, es wegzulassen...

    bb

    0
  • D

    Richtig ist, wenn du die erwarteten Typen benutzt. Das ist bei einem float Literal halt das ".f".

    0
  • ?
     

    WINGDIAPI void APIENTRY glClearDepth (GLclampd depth)
typedef double GLclampd;
    0
  • X

    Das ist hingegen auch intressant 🙂

    0
  • A

    Das ändert für dich im Endeffekt nur eine andere Tatsache: jetzt solltest du

    glClearDepth(3.0)

    schreiben, also auf jeden Fall einen Punkt.

    0
  • B

    Es gibt keine Performance-Gründe für oder gegen "1.f". Es gibt nur lauter mehr (potentielle Überladung) oder weniger (Einsparen von impliziten Konvertierungen) nachvollziehbare Pseudogründe, die du schön kompakt hier im Thread nachlesen kannst. Wenn du sie glaubst, machst du es auch so, wenn nicht, dann nicht.

    0
  • ?

    x4rd3n schrieb:

    Oder kostet diese implizierte Koverntierung von int nach float prozessor zeit?

    Höchstens beim Kompilieren.

    0
  • K

    Ich vertraue einfach dem Compiler, den richtigen Typ fuer 1 oder 1.0 herauszufinden. Bei Ueberladung geht das meist schief, aber da darf er mir dann auch eine Warnung preasentieren. Ich lese die sogar.

    0
  • Mod

    knivil schrieb:

    Ich vertraue einfach dem Compiler, den richtigen Typ fuer 1 oder 1.0 herauszufinden. Bei Ueberladung geht das meist schief, aber da darf er mir dann auch eine Warnung preasentieren. Ich lese die sogar.

    Das Problem ist aber, dass er, wenn eine neue Überladung hinzukommt, nicht mehr warnt, sondern stillschweigend die falsche Funktion nimmt. Schließlich willst du ja eindeutig die neue int Variante der Funkton und nicht die alte mit double, sonst hättest du ja ein double-Argument hingeschrieben.

    0
  • K

    Stimmt ...

    0
  • N
     

    void foo(float);
foo(1.f); // (1)
foo(1);   // (2)

    Ich finde hier (1) durchaus klarer, weil gleich ersichtlich ist, dass ein Fliesskommatyp verwendet wird. Wenn ich z.B. foo() ein Weilchen nicht mehr benutzt habe und dann merke, eine leichte Modifikation des Arguments wäre angebracht, kann ich gleich 1.5f schreiben. Sonst bin ich verunsichert, weil ich davon ausgehe, dass Ganzzahlen erwartet werden (nur meine Sichtweise).

    Wieso sollte man nicht die richtigen Literale benutzen? Man setzt ja auch nicht false ein, wenn 0 gebraucht wird...

    0
Anmelden zum Antworten