Dieses AUTO ist cool (Teil 2)

Wir wissen nun, dass Großvater C sein auto nie benutzt hat und es in der Garage verrosten ließ.

Doch sein Enkel C++ 11, ein bekennender auto-Freak, zerlegte die Karosserie, entfernte die Spuren des Zahns der Zeit und baute sich daraus einen neuen Boliden, der jedoch bald ein Eigenleben entwickelte.

Dieser wurde zu einer Rennsau, die bei fast jedem Wettrennen als Nummer 1 über die Ziellinie sauste
… vorausgesetzt: Es saß der richtige Fahrer hinterm Lenkrad.


Wenn man unter C++ weiter “klassisch” programmiert, könnte man denken, dass man auto nicht braucht.
Es ist sogar übersichtlicher, wenn man Datentypen selbst ausschreibt (int x = 42;) anstatt alles von auto erledigen zu lassen (auto x = 42;).

Doch spätestens, wenn man mit Templates und Spezialisierungen arbeitet, sind Typen bei der Deklaration nicht mehr zwingend vorhersehbar.
Doch der Compiler weiß bei der Instanzierung ganz genau, mit welchen Typen er arbeitet, und genau hier wird auto zum gefeierten Heilsbringer.

template<class T> struct next_greater_type
{
	typedef long double type_t;	/* finally the "greatest" type */
};

template<> struct next_greater_type<char>
{
	typedef short type_t;
};

template<> struct next_greater_type<short>
{
	typedef long type_t;
};

template<> struct next_greater_type<long>
{
	typedef long long type_t;
};

template<> struct next_greater_type<long long>
{
	typedef double type_t;
};


template<class T>
typename next_greater_type<T>::type_t multiply(T const& t1, int t2)
{
	typedef typename next_greater_type<T>::type_t greater_type_t;
	
	greater_type_t a = greater_type_t(t1);
	greater_type_t b = greater_type_t(t2);
	
	greater_type_t c = a * b;
	return c;
}

int main()
{
	char c = 127;
	short s = 32767;
	long l = 2147483647L;
	long long ll = 9223372036854775807LL;

	auto result1 = multiply(c, 4);	// short result
	auto result2 = multiply(s, 4);	// long result
	auto result3 = multiply(l, 4);	// long long result
	auto result4 = multiply(ll, 4);	// double result
	
	return 0;
}

Im Beispiel wird für jeden Zahlentypen der nächst größere festgelegt. Die generische “Multiplikation” soll so einen Ausgabetypen festlegen, der ohne Verlust das Ergebnis enthalten kann.

Zugegeben, das Beispiel ist wirklich sehr exemplarisch und wenig praxisnah. Aber es zeigt, dass auto einem den Aufwand abnimmt, stets über den template typedef den Ergebnistypen selbst zu bestimmen.

auto und R-Value Referenzen

Seine größte Stärke spielt auto meines Erachtens mit auto&& aus.

Denn wir Programmierer machen gerne den Fehler durch ungenaue und schlecht passende Datentypenangaben Optimierungen zu verhindern.

Gibt eine Funktion eine const-Referenz zurück, sollte diese auch genau so entgegengenommen werden. Nimmt man sie als neue Instanz an, entsteht eine (oft sinnlose) Kopie, die Speicher und CPU-Zeit frisst.

std::string const& get_text();
...
std::string x = get_text();	// falsch!
std::string const& y = get_text(); //richtig!

Genau hier hilft uns auto&&, denn dieses Konstrukt garantiert, dass die Variable den perfekten Typen erhält.

std::string get_copy();
std::string& get_reference();
std::string const& get_const_reference();
std::string&& get_rv_reference();

void lame_foo()
{
	auto a = get_copy();			// std::string / copy
	auto b = get_reference();		// std::string / copy
	auto c = get_const_reference();	// std::string / copy
	auto d = get_rv_reference();	// std::string / move
}
void smart_foo()
{
	auto&& a = get_copy();				// std::string&&
	auto&& b = get_reference();			// std::string&
	auto&& c = get_const_reference();	// std::string const&
	auto&& d = get_rv_reference();		// std::string&&
}

In lame_foo löst auto stets einen std::string aus, was mit Ausnahme der letzten Zeile immer ein Kopieren des Strings erfordert.

smart_foo hingegen nutzt std::string&& um Kopien durch Move-Konstruktion abzufangen und im Fall von “gewöhnlichen” Referenzen werden diese erkannt und als eben solche ohne Performanceverlust entgegengenommen.

Kurz gesagt: Perfekt.

Fazit

auto zählt im modernen C++ ganz klar zu meinen Favoriten.
Mehr kann man dazu gar nicht sagen.

Mein Problem in der Entwicklung ist allerdings, dass ich aus Rücksicht auf ältere Compiler (z.B. für Windows CE ), immer noch oft auf dieses Feature verzichte.

Doch bei neuen Projekten ist auto absolut Pflicht!


Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!