Type inference - gutes C++0x-Feature?

Shade Of Mine

Nexus schrieb:

Aus einem schon etwas älteren Spiel von mir

Da sehe ich durch auto keinen Informationsverlust.
Die Variablen sind eh ewig weit weg von ihrer Verwendung deklariert.

Hast du vielleicht noch ein anderes?

PS:
Nicht falsch verstehen, aber in F# zB wird alles über Type Inference gemacht und das fühlt sich absolut natürlich an. Deshalb tue ich mir gerade schwer negativ Beispiele zu aktzeptieren...

Zeus

Shade Of Mine schrieb:

Nicht falsch verstehen, aber in F# zB wird alles über Type Inference gemacht und das fühlt sich absolut natürlich an. Deshalb tue ich mir gerade schwer negativ Beispiele zu aktzeptieren...

Was haben den alle Sprachen mit Type Inference gemeinsam? Referenzsemantik?

Nexus

Shade Of Mine schrieb:

Die Variablen sind eh ewig weit weg von ihrer Verwendung deklariert.

Findest du? Man sieht sie immerhin direkt, wenn man den verwendenden Code anschaut. Ich finde das Beispiel ohne Typinferenz wirklich übersichtlicher.

Shade Of Mine schrieb:

Hast du vielleicht noch ein anderes?

Schon, aber ob es besser ist...? Worin läge hier der Vorteil von auto ?

bool aboveTile = (obj.GetBottom() - vy - std::max(vx, 0.f) - tolerance <= tileY * Tile::TileSize);

Zeus schrieb:

Was haben den alle Sprachen mit Type Inference gemeinsam? Referenzsemantik?

Nein, C++ hat ja Wertsemantik. Was hat das überhaupt mit Typinferenz zu tun?

Ich sehe, was Lesbarkeit angeht, zwischen (Beispieltyp aus der Luft gegriffen)

std::vector<std::pair<std::vector<foo*,std::string>>*> *bar = obscure_function();

und

ObscureTypedef *bar = obscure_function();

und

auto bar = obscure_function();

überhaupt keine Unterschiede. Hilfreich zum Verstehen des Codes ist keins von denen dreien - aber wenn man mal einen solchen aus der Reihe tanzenden Typen hat, kommt man einfach nicht drum rum.

Schwieriger wirds dann schon, wenn ich den Code nicht nur verstehen soll, sondern was ändern und direkt mit dem Typen arbeiten muss:

auto bar = obscure_funciton();

//hmm... mal nachdenken
bar[i].first->DoSomething(); //mist, compilerfehler

//hmm... vll. doch eher so?
(*bar)[i].first->DoSomething(); //hm, passt auch nich

und so weiter.

Da würde ich die ursprüngliche Fassung

std::vector<std::pair<std::vector<foo*,std::string>>*> *bar = obscure_function();

schon bevorzugen.

Wobei man auch sagen muss, dass ich selbst hier auto bevorzugen würde (aufgrund von Schreibfaulheit), falls Visual Assist X und Konsorten auto endlich mitparsen würden.

Oder noch schöner: Wenn man einfach nen Button klickt (oder ne Tastenkombination drückt) und es wird ne schöne Textersetzung losgefahren, die mir den tatsächlichen Typen hinschreibt.

Auf alle Fälle sind das aber eher Unangenehmheiten beim Tippen und Kompilieren (im schlimmsten Fall 3 oder 4 mal kompilieren anfangen bis man die Syntax richtig hat). Ich sehe da recht wenige Möglichkeiten, übel unsichtbare Bugs zu erzeugen. Was Codeverstehen angeht, nehmen sich alle 3 Beispiele nicht viel, denke ich.

Ob der Schreibaufwand, den man sich durch auto zunächst spart, größer ist, als der, der dann entsteht wenn man später wieder zum Code zurückkehren muss, wird man wohl nur mit Erfahrung mit dem Wort rausfinden können.

Ansonsten, fürs durchiterieren von Ranges ist auto immer gut.