Month: November 2014

0

Auto und for-Schleifen

Posted on by

Nein, man lernt tatsächlich nie aus. Seit C++11 können wir ja schreiben

vector data{};
...
for(auto e : data) { cout << e; };

Das ist schon ganz schön praktisch gegenüber for(vector it=data.begin();...) { cout << *it; }, hat aber den großen Nachteil, dass erstens e hier oimmer kopiert wird und zweitens Änderungen an e sich nicht in data auswirken.

Stimmt, und deshalb erzähle ich auch immer, dass man daran danken sollte, in solchen Schleifen zuerst immer zu prüfen, ob man stattdessen nicht auto& oder const auto& verwenden sollte:

vector<int> data{};
...
for(auto& e : data) { e += 1; };

Das verhindert Kopie und data wird auch wirklich modifiziert.

Jetzt werde ich gerade erinnert, dass das nicht immer reicht. Zum Beispiel kann es keine (echte) Referenz in einen vector<bool> geben, weil man einzelne Bits nicht adressieren (also referenzieren) kann. Das gäbe mit auto& einen Fehler.

Daher, jetzt meine neue Regel: Man probiere es mit auto&&. Das ist dann der Einsatz der Meyerschen Universellen Referenzen, soweit ich das erkennen kann:

vector<int> data{};
...
for(auto&& e : data) { e += 1; };

Im Effekt bekommt man eine &, wenn nötig und eine &&, wenn erlaubt. Die genaue Erklärung was passiert, folgt in einem Detailbeitrag. Bis dahin probiere ich diese neue Merkregel mal aus.

Nachtrag

In einem Vorschlagsdokument des C++-Standards steht das Dilemma beschrieben:

What should we do about this problem? We can teach users to write
for (auto& elem : range) or for (const auto& elem : range), but they’re
imperfect (for proxies or mutation, respectively), and they require novices to
be introduced to auto and references earlier than otherwise necessary.
As explained immediately below, for (auto&& elem : range) is superior, but
it’s terrible to teach to novices. Even experienced C++98/03 programmers can
find it difficult to learn how rvalue references, the template argument
deduction tweak, and reference collapsing interact to produce what Scott Meyers
calls „universal references“ (see [1]), and auto&& is far less commonly seen
than T&& in perfect forwarding.

Andererseits sagt Herb Sutter in Back To Basics, dass man auto&& nicht für lokale Variablen verwenden soll. Da stimme ich im Prinzip auch zu, aber grüble, ob sein Gesagtes nicht bei diesen auto-for-Schleifen eine Ausnahme sind. Hauptsächlich im Bezug der Einfachheit allerdings.

„STL“ gibt etwas mehr Erklärung hier und bezieht auch den kommenden C++-Standard (wahrscheinlich) mit ein, der…

Ausblick

…eine neue Syntax enthält, die genau diese Schreibweise abkürzt: Einfach den gesamten Typen in der Schleifendeklaration weglassen und der Compiler macht daraus automatisch auto&&:

vector<int> data{};
...
for(e : data) { e += 1; };

…in der (fernen) Zukunft (vielleicht).

Zusammenfassung

Mit all den Informationen, die ich nun habe, möchte es noch einmal zusammenfassen. Vor allem „STL“ (oben) und Howard Hinnant konnten mir Dinge klären

Ab C++17 gilt: Verwende for(e :...) wann immer möglich.

vector<int> data{};
...
for(e : data) { e += 1; };

Bis dahin, mit C++11 alleine, gilt:

In 99.9% der Fälle und somit für alle Entwickler bis zum braunen Gürtel gilt (immernoch): Verwende for(auto &x: ...) oder for(const auto &x: ...) wenn Du kannst und kopiere nur wenn nötig:

vector<int> data{};
...
for(auto &e : data) { e += 1; };
...
for(const auto &e : data) { cout << e; };

Entwickler mit dem schwarzen Gürtel, und/oder innerhalb einer Bibliothek mit einem Funktionstemplate für den Typ von data, kann es sinnvoll sein for(auto &&x: ...) zu verwenden:

vector<int> data{};
template 
void func(T&& data) {
  ...
  for(auto &&e : data) { e += 1; };
  ...
}

Denn ob RValue-Ref oder LValue-Ref ist nur dann relevant, wenn data für seine Iteratoren (temporäre) Proxy-Objekte benötigt (wie vector<bool>). Selbst wenn man dieses Konstrukt außerhalb eines Funktionstemplate verwendet, wird man && nicht brauchen, sondern kann sich bewusst zwischen [const] auto& und [const] auto entscheiden.

0

FAQ001: modern102.cpp compiliert nicht auf Microsoft Visual Studion 2012

Posted on by

FAQ

Habe soweit das Programm modern102.cpp in Visual Studio 2012 übernommen. Wenn ich das Prgramm ausführen lassen möchte, bekomme ich als Fehlermeldung:

error C2601: ‚table‘: Lokale Funktionsdefinitionen sind unzulässig

Mir wird genau an der Stelle:

…static std::map<int, int> table{};…

bei der geschweiften Klammer angezeigt, dass was nicht stimmt. Bei genaueren Hinsehen in Ihrem Buch, stehen unter den beiden geschweiften Klammern {} jeweils ein Punkt.

 


Das klingt sehr danach, dass der Compiler C++11-Konstrukte zurückweist.
Hier sehen Sie

dass „Visual Studio 2012“ zum Beispiel die „Initializer Lists“ nicht kennt, also die
Initialisierung mit „{…}“. Das ist hier das Problem.

Im Anhang können Sie alternative Schreibweisen für C++11-Konstrukte finden, die Ihr Compiler nicht kennt. Konkret schreiben Sie statt

   static std::map<int, int> table{};

in MSVC2012:

   static std::map<int, int> table;

Wenn Sie die Möglichkeit haben, sollten Sie auf die neueste Version von Visual Studio wechseln. Wenn nicht, müssen Sie teilweise auf alternative Schreibweisen ausweichen.

Möglicherweise hilft auch ein kleines Update, das habe ich aber nicht selbst probiert.

In early November 2012, Microsoft announced the Visual C++ Compiler November 2012 CTP, which adds more C++11 functionality to Visual Studio 2012.

Im buch können Sie Punkte unter den Klammern sehen, die auf ein C++11-Feature hindeuten (wird in Abschnitt 1.2, „Verwendete Formatierungen“, S. 27, eingeführt). Wenn an solchen Stellen etwas schief geht und der Compiler meckert, sollten Sie skeptisch werden. Hier ist die „Initialisierungsliste“ gepunktet unterstrichen — weil „{}“ so wenig Text ist, erschient diese Linie als nur zwei Punkte.