3. Schlüsselwort AUTO in c++0x++ , Diskussion, Erläuterung

Schlüsselwort AUTO in c++0x++ , Diskussion, Erläuterung

  • C

    Dravere schrieb:

    Ich verwende es zum Teil sogar schon für skalare Typen.

    Das wird halt dann interessant, wenn man keinen expliziten Typ als Rückgabewert hat, sondern z.B. nur eine Zahl. Dann nimmt man doch mal lieber unsigned oder float. Ansonsten stimme ich dir zu, bei (fast*) allem wo man eine Funktion nimmt die irgendwas zurückgibt, ist auto super.

    * Mit Referenzen sollte man aufpassen, wenn man nur eine Referenz will, sonst wird das nämlich kopiert.

    0
  • P

    cooky451 schrieb:

    * Mit Referenzen sollte man aufpassen, wenn man nur eine Referenz will, sonst wird das nämlich kopiert.

    Wo ist das Problem? Wenn ich explizit eine Referenz haben möchte schreibe ich halt auto& 🙂 Darauf müsste ich beim Ausschreiben des Typen genauso achten, ist also unabhängig von der auto-Geschichte.

    cooky451 schrieb:

    Dravere schrieb:

    Ich verwende es zum Teil sogar schon für skalare Typen.

    Das wird halt dann interessant, wenn man keinen expliziten Typ als Rückgabewert hat, sondern z.B. nur eine Zahl.

    Beispiel? Man hat doch immer einen expliziten Typen als Rückgabetyp. Und grade wenn das einer der implementatoin-defined Typen ist, ist auto erst recht gut - man hat dann genau den Typen den man braucht. groß/genau genug aber nicht zu groß/genau.

    0
  • C

    pumuckl schrieb:

    cooky451 schrieb:

    * Mit Referenzen sollte man aufpassen, wenn man nur eine Referenz will, sonst wird das nämlich kopiert.

    Wo ist das Problem? Wenn ich explizit eine Referenz haben möchte schreibe ich halt auto& 🙂

    Ou, daran hatte ich gar nicht gedacht, das ist natürlich cool. 👍

    pumuckl schrieb:

    cooky451 schrieb:

    Das wird halt dann interessant, wenn man keinen expliziten Typ als Rückgabewert hat, sondern z.B. nur eine Zahl.

    Beispiel? Man hat doch immer einen expliziten Typen als Rückgabetyp. Und grade wenn das einer der implementatoin-defined Typen ist, ist auto erst recht gut - man hat dann genau den Typen den man braucht. groß/genau genug aber nicht zu groß/genau.

    Beispiel?

    for (auto i = 0; ..)
    0
  • K

    cooky451 schrieb:

    pumuckl schrieb:

    cooky451 schrieb:

    Das wird halt dann interessant, wenn man keinen expliziten Typ als Rückgabewert hat, sondern z.B. nur eine Zahl.

    Beispiel? Man hat doch immer einen expliziten Typen als Rückgabetyp. [...]

    Beispiel?

    for (auto i = 0; ..)

    0 ist nicht nur einfach eine Zahl sondern hat einen Typ: int. auto verhält sich hier genauso wie Template-Argument-Deduction bei Funktionstemplates.

    0   --> int
0L  --> long int
0u  --> unsigned int
0uL --> unsigned long int
0.0 --> double
0.f --> float

    Lässt man das u bei Ganzzahlen weg, schreibt dafür die Zahl aber in Hex hin, erhält man auch ggf eine Zahl eines vorzeichenlosen Typs.

    Eine Sache kann auto aber mehr:

    auto foo = {1,2,3}; // decltype(foo) --> initializer_list<int>

    Das klappt nur bei auto und nicht bei Funktionstemplates.

    0
  • C

    krümelkacker schrieb:

    0 ist nicht nur einfach eine Zahl sondern hat einen Typ: int. auto verhält sich hier genauso wie Template-Argument-Deduction bei Funktionstemplates.

    Ja, schon. Aber dann schreibst du wirklich statt "unsigned i = 0" "auto i = 0u"?

    0
  • K

    Nö, das habe ich nicht behauptet. Aber ich verwende schonmal entsprechende Suffixe. Blödes aber einfaches Beispiel:

    bool is_odd(int z) { return z & 1u; }

    Damit erzwinge ich hier eine arithmetische Konvertierung int -> unsigned von z bevor & angewendet wird. Diese Konvertierung garantiert mir das Bitmuster eines 2er-Komplements; denn sonst könnte das bei negativen Zahlen und einer anderen Darstellung (1er Komplement) nach hinten losgehen. Die Bitoperationen bei negativen Werten sind einfach nicht klar festgelegt. Bei vorzeichenlosen Zahlen schon.

    0
  • V

    krümelkacker schrieb:

    Nö, das habe ich nicht behauptet. Aber ich verwende schonmal entsprechende Suffixe. Blödes aber einfaches Beispiel:

    bool is_odd(int z) { return z & 1u; }

    Damit erzwinge ich hier eine arithmetische Konvertierung int -> unsigned von z bevor & angewendet wird. Diese Konvertierung garantiert mir das Bitmuster eines 2er-Komplements; denn sonst könnte das bei negativen Zahlen und einer anderen Darstellung (1er Komplement) nach hinten losgehen. Die Bitoperationen bei negativen Werten sind einfach nicht klar festgelegt. Bei vorzeichenlosen Zahlen schon.

    Aber täte

    bool is_odd(int z) { return z%2==0; }

    nicht das besser tun? Weil man gar nicht um Bitgefrickel nachdenken muß, sondern eher in der Mathematik bleibt.

    0
  • C

    volkard schrieb:

    nicht das besser tun? Weil man gar nicht um Bitgefrickel nachdenken muß, sondern eher in der Mathematik bleibt.

    Wurde das nicht nur mit unsigned optimiert? 🤡

    0
  • V

    cooky451 schrieb:

    Wurde das nicht nur mit unsigned optimiert? 🤡

    Verwechselst Du das mit %1024?

    0
  • K

    volkard schrieb:

    Aber täte

    bool is_odd(int z) { return z%2==0; }

    nicht das besser tun?

    Es war leider das erste Beispiel, was mir einfiel. Ich würde wahrscheinlich auch einfach z%2**!=**0 der Lesbarkeit wegen schreiben und auf schlaue Compiler vertrauen, die daraus wieder eine Bitfrickelei machen. 😉

    0
  • C

    volkard schrieb:

    cooky451 schrieb:

    Wurde das nicht nur mit unsigned optimiert? 🤡

    Verwechselst Du das mit %1024?

    Ne, ich beziehe mich da auf http://www.c-plusplus.net/forum/294476

    0
Anmelden zum Antworten