Ehrlich gesagt, ich sehe hier nur Bequemlichkeit und noch mehr Unleserlichkeit.
Hat auto noch irgendeine Funktion, die mir grade verborgen bleibt?

std::vector<std::array<int,2> >::const_iterator

und

auto

entscheiden müsste, würde ich wohl letzteres vorziehen.

Das zwingende Grund sind aber Lambdas:

auto f = [](){return 0;}; // nicht ohne auto machbar
void(*ff)() = [](){return 0;}; // langsamer
std::function<void()> fff = [](){return 0;}; // langsamer

std::vector<int>::iterator getIter();

int main()
{
	// ...
	auto it = getIter();
	// ...
	std::vector<int>::iterator it2 = getIter();
}

Das klappt und ist schnell geschrieben. Aber nach 2 Wochen änderst du jetzt den Container hinter deiner Klasse/Funktion/sonstwas, und zack! die zweite Methode klappt nicht auf Anhieb.

Andererseits, für Kleinkrams oder richtige Deklarationen würde ich nie auto nutzen. Ich will sehen, was meine Variablen für einen Typ haben (ansonsten würd ich Javascript oder PHP machen). Aber gerade für Iteratoren oder kleine Hilfsvariablen, da lohnt sich auto echt, wie ich finde.

Aber nach 2 Wochen änderst du jetzt den Container hinter deiner Klasse/Funktion/sonstwas, und zack! die zweite Methode klappt nicht auf Anhieb.

Ich weiß aber nicht, ob das gut ist. Mir wäre es lieber, wenn ich den Code anpassen müsste, dafür aber genau sehe, was alles betroffen ist. Wenn etwas trotz Änderungen kompiliert, finde ich das gefährlich. Mit impliziten Typumwandlungen bin ich schon öfter auf die Nase gefallen.

Also wenn ich zwischen

std::vector<std::array<int,2> >::const_iterator

und

auto

entscheiden müsste, würde ich wohl letzteres vorziehen.

Das zwingende Grund sind aber Lambdas:

auto f = [](){return 0;}; // nicht ohne auto machbar
void(*ff)() = [](){return 0;}; // langsamer
std::function<void()> fff = [](){return 0;}; // langsamer

Okay, für Templates ist es wirklich gut. Da muss ich zustimmen.
Aber generell würde ich persönlich es nicht verwenden.

Andererseits, für Kleinkrams oder richtige Deklarationen würde ich nie auto nutzen

Das war auch mein Gedanke.

Mit impliziten Typumwandlungen bin ich schon öfter auf die Nase gefallen.

Da gibt es aber keine implizite Typumwandlung.

Mechanics schrieb:

Mit impliziten Typumwandlungen bin ich schon öfter auf die Nase gefallen.

Da gibt es aber keine implizite Typumwandlung.

Ich weiß. Aber es ist im Grunde was ähnliches, deswegen habe ich das erwähnt. Es ist etwas, das einfach kompiliert, obwohl man etwas geändert hat und vielleicht gar nicht alle Anwendungen bedacht hat.

Andererseits, für Kleinkrams oder richtige Deklarationen würde ich nie auto nutzen

Das war auch mein Gedanke.

Hä? Was hab ich denn da geschrieben? Achso hab ich das gemeint gehabt. Ich glaub ich stell das nochmal klar.

auto würde ich nur für Kleinkram verwenden, wie Iteratoren oder temporäre nicht triviale Variablen, die von irgendwelchen Funktion/Methoden initialisiert werden.

Aber für triviale Daten wie ints, doubles oder auch Widget* würde ich nie auto benutzen.

Ich weiß aber nicht, ob das gut ist. Mir wäre es lieber, wenn ich den Code anpassen müsste, dafür aber genau sehe, was alles betroffen ist. Wenn etwas trotz Änderungen kompiliert, finde ich das gefährlich.

auto iterator = container.begin();

Man weiß doch, dass es ein passender Iterator ist. Ob es nun über vector, list, string oder was auch immer iteriert, ist an dieser Stelle vollkommen unwichtig und man muss nur an einer Stelle etwas verändern und spart sich gleichzeitig den blöden Umweg über ein typedef.

Wer

auto x = 5;

schreibt ist selbst schuld, weil intuitiv nicht ersichtlich ist, welcher Typ x denn genau sein kann, aber bei iteratoren ist das wissen "ein passender Iterator" doch genug und auch vor einem cast habe ich gerne auto.
Bei

auto foo = static_cast<EineAndereKlasse*>(bar);

spart man sich nunmal doppelte Tipparbeit gegenüber

EineAndereKlasse* foo = static_cast<EineAndereKlasse*>(bar);

auto iterator = container.begin();

Ja, sowas finde ich auch ok. Das ist noch gut überschaubar. Aber sobald es um Rückgabewerte von Funktionen geht, wäre ich schon vorsichtiger. Man weiß nicht, was die Funktion macht und was sie zurückgibt.

Ich sehe das so. In deinem Code taucht der Datentyp einer Variable nur einmal auf und zwar bei der Definition. Im restlichen Verlauf des Codes benutzt du nur noch den Variablennamen. Der Variablenname begeleitet dich in deinem Programm, nicht der Datentyp. Insofern ist der Datentyp nicht so relevant, wie die Aussagekräftigkeit eines Namens.

Dein Code sollte sich einfach und bequem lesen und verstehen lassen. Selbst für sich sprechen. Ein Variablenname ist das A und O hierbei. Da interessiert der Datentyp nicht. Wenn interessiert das T<..>::XYZ vor einem Iterator, arbeitet und schreibe sauberen Code und minimiere alle redundaten Information, die nur den Lese- und Verständnisfluss des Codes erschweren.

Mein Tipp, benutze auto wo es geht und "schön" aussieht. Mit der Zeit wirst du es raus haben und die Community sich daran gewöhnen. Es ist so wie mit dem var in C#. Da hat es auch ein Weilchen gedauert, bis man damit warm wurde.

http://www.c-plusplus.net/forum/306015

Bei den meisten Punkten wuerde ich wiedersprechen

Bei welchen Punkten?

Das sich Code wie ein Roman lesen sollte, sind wir uns wohl einig. Das auto für mich ein gutes Hilfsmittel dafür ist, anscheinend nicht. Teile deine Ansichten mit mir

Das sich Code wie ein Roman lesen sollte, sind wir uns wohl einig.

Ja. Aner meines Erachtens kollidiert diese Anforderung mit ausagekraeftigen Variablenname. Beispiel:

it
iter
iterator
cosy_iterator
cosy_item_iterator
cosy_item_list_iterator
cosy_item_list_iterator_last

Ich benutze haeufig das erste. Wenig aussagekraeftig! Haeufig sehe ich, dass der Typ im Variablennamen codiert wird, um aussagekraeftige Namen zu erhalten. Noch schlimmer ist CamelCase fuer mich. Wenn ich mal die Uebersicht verliere, dann hilft mir die IDE, den Typ schnell herauszufinden. Typen sind alles in einer streng typisierten Sprache, Variablennamen sind ... nichts.

Aber vielleicht bin ich dazu zu sehr matheaffin. Die Schreiben gern mal: Sei a ein schiefsymmetrischer Tensor ... was sich im Code dann niederschlaegt.

auto a = mache_schief_symmetrischen_tensor<...>(....)

Stell dir mal nen batzen Sourcecode vor. Mittendrin taucht sowas auf:

NetworkInterfaces networkInterfaces = getAllInterfaces();

for(size_t i = 0; i < networkInterfaces.size(); ++i)
{
    NetworkInterface interface = networkInterfaces;
    cout << interface.addr();
}

Du liest: "NetworkInterfaces networkInterface, get alle Interface." Dann kommt das for-i Signal und du schaust nur noch auf "0, .size(), ++i". "NetworkInterface interface aktuelles interfaces. Ausgabe Adresse".

Im Gegensatz zu:

auto networkInterfaces = getAllInterfaces();

for(size_t i = 0; i < networkInterfaces.size(); ++i)
{
    auto interface = networkInterfaces[i];
    cout << interface.addr();
}

"networkInterfaces, get alle Interface. for-i Signal "0, ,.size(), ++i". "interface, aktuelles Interfaces. Ausgabe Adresse".

Noch besser ist es natürlich so:

for(auto interface : networkInterfaces)
    cout << interface.addr();

for-each Signal: "interface, networkInterfaces, Ausgabe alle Adressen"

Ein auto erhöht IMHO ungemein den Lesefluss. In einem großen Projekt, wo man den Code lesen und verstehen will, wo der Code nachhaltig sein soll, da braucht man nicht zu wissen, das zum Beispiel networkInterfaces vom Typ NetworkInterfaces ist. Denn was bringt dir das.

Aus der Entwicklersicht: Du drückst in deiner IDE ehe nach dem Variablennamen auf Punkt und siehst die Funktionen dahinter. Programmierst nur noch mit dem Variablnennamen. Du weißt intuitiv, was dich erwartet. getAllInterfaces() signalisiert dir das das in networkInterfaces eine Aufzählung drin steckt und so mit Sicherheit op[] und size(). Du liest drüber und speicherst ab, dass du in networkInterfaces mehrere NetworkInterface hast. Das siehst du aber auch schon direkt im Variablennamen wieder ([i]networkInterface*s).

Aus Lesersicht: (siehe oben) + du siehst nur noch networkInterfaces. Aus dem Lesefluss und dem Namen hast du dir schon "eingefühlt" was networkInterfaces ist. Was drin steckt und was man damit machen kann. Den Datentyp weißt du nichtmehr. Musst du auch nicht, wenn du die Programmlogik verstehen willst.

PS: In meiner Vorschau steht "[i:778abd26e1]". Immer wenn ich Vorschau drücke, ändert sich die Zahl. In meinem Editierfenster steht aber keine seltsame Zahl nachm i!

PPS: Das i kollidiert irgendwie mit dem in meinem letzten Satz.
PPPS: http://www.c-plusplus.net/forum/319720

//Typ ist offensichtlich
auto thing = std::make_unique<thing>();

//ist mir egal welchen Typ die Summe hat, Hauptsache da wird nicht abgeschnitten
auto result = a + b;

template <class F, class G>
void overly_functional_function(F const &f, G const &g)
{
	f()(g);

	//Die Aufteilung auf zwei Statements ist nur mit auto oder decltype allgemein möglich.
	//Genau genommen geht hier RValue-ness verloren, aber wer ist schon so verrückt den Aufrufoperator mit && zu qualifizieren?
	auto &&a = f();
	a(g);
}

// (...) aber wer ist schon so verrückt den Aufrufoperator mit && zu qualifizieren?

Ey du bringst bloss Sone auf dumme Ideen...

Ich sehe den Sinn von auto nicht

Auto wurde erfunden weil Laufen auf Dauer recht mühsam ist.

Ich sehe den Sinn von auto nicht

Auto wurde erfunden weil Laufen auf Dauer recht mühsam ist.

du meinst bestimmt das Bipedale Iterieren über festen Untergrund

EOP schrieb:

Ich sehe den Sinn von auto nicht

Auto wurde erfunden weil Laufen auf Dauer recht mühsam ist.

du meinst bestimmt das Bipedale Iterieren über festen Untergrund

LOL - der ist auch echt gut.