Uncategorized

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

Kein rand() mehr

Posted on by

Soso, der C++14-Standard wurde also einstimmig angenommen. Ende des Jahres werden wir also das Update kaufen können. Natürlich kann man auch den kostenlosen letzten „Working Draft“ nehmen, aber ein paar kleine Änderungen sind da nicht enthalten.

Wie zum Beispiel, dass das von C kommende rand() als Funktion nicht mehr verwendet werden soll — diese ist jetzt „deprecated“. Stattdessen wird die Verwendung der C++-Template-Sammlung aus <random> empfohlen.

Ich muss dazu mal ein konkretes Beispiel raussuchen.

Ich bin auf eine Liste von Namen für Programmierparadigmen gestoßen, die wir alle kennen, aber denen köstliche und einprägsame Namen gegeben wurden:

  • Die Joda-Bedingung if(value.equals("Wert"))` ersetzt if("Wert".equals(value))
  • Pokemon Exception Handling wenn man einfach mit try { block } catch(...) { handler } alles fängt.
  • Egyptian brackets ist, enn die then-{-Klammer noch auf die Zeile des ifs geschrieben wird
  • Aber am schönsten für strictly typed C++-Liebhaber finde ich die stringly typed Sprachen PHPs oder JavaScript

 

0

Posted on by

Was ich hier einem Freund über George R. Martin geschrieben habe will ich euch nicht vorenthalten. Ich hoffe es kommt auch unübersetzt rüber.

Actually, I can totally follow that reasoning. Not that I think of it I myself have the most proliferating writing sessions bereft of my internet connection: Either in the train or in a beer garden. That is not bereft of distractions, mind you. I especially love watching people on the seats and benches when I look up.

Oh well, while George uses Wordstar 4.0, I can top that: My emacs is the ultimate non-distractor, I can tell you. I have to admit that an open internet connections is the factor offering too many distractions.

Alas, I can not always choose that fruitful environment. For one, I have to use stackoverflow occasionally (and no offline backup if it is available, yet) and for the other, after three beer it is more efficient to stop writing then to correct the produced sermon later.


 

Update: I had to disable comments on this page (spam, spam, spam). If you have one, don’t hesitate to send me an EMail, I will gladly put your comment here. Sorry or the inconvenience.

Posted on by

2

Keine Wert-Initialisierung mehr? — oder eine Fürsprache für Privatisierung

Posted on by

Ist es nicht ein Segen, dass man eine eigene neue Klasse auf sooo viele Arten Initialisieren kann?

struct Person {
    string name_;
    int alter_;
    string ort_;
};

Nur 3 Membervariablen, aber 4 tolle Möglichkeiten zum Initialisieren:

Person otto {"Otto", 44, "Aachen"};
Person hans {"Hans", 33};
Person paul {"Otto"};
Person kurt {};

Weil wir die {} hier verwenden werden alle Member initialisiert — die „überzähligen“ Wert-Initialisiert“. Also immer mit {} initialisieren, bitteschön, denn Person xxx; wird *nicht initialisiert. Iih-ba!

Aber ist das überhaupt gut so? Warum sollte man nur einige daten von Person initialisieren wollen? Gut, ich kann mir Szenarien vorstellen, wo man mit der Wert-initialierung zufrieden ist, aber alle diese Möglichkeiten zulassen? Wenn der Datentyp so gedacht ist, dass man mit 0, 1, 2 oder 3 Parametern initialisieren kann, wenn das Sinn ergibt, dann kann ich auch die entsprechenden Konstruktoren dafür bereitstellen. Das ist dann expliziter, und der Leser der Datenstruktor muss nicht überlegen „ist das überhaupt so gedacht?“.

Initialisierung von Typen mit private Daten

Daher, warum nicht gleich private Daten haben? Das verhindert nämlich auch die Wert-Initialisierung. Hier kommt dann höchstens die Null-Initialisierung ins Spiel. Aber der Name ist egal, wir kennen alle den Effekt:

„Wenn Sie keinen Konstruktor selbst definieren, dann erzeugt der Compiler den Default-Konstruktor.“

Dankeschön. Und was bedeutet das? Man hört, der macht gar nichts. Ja, fast. Der macht (manchmal) nichts, aber vorher, da passiert das Interessante.

Aber sehen wir uns ein Beispiel an.

class Rect {
    int area_;  // private Daten
public:
    int x_, y_;
    void set(int x, int y) { x_=x; y_=y; area_=x_*y_; }
    int calc() { return area_; }
};

Da Sie von außen nicht mehr direkt auf diese Membervariable zugreifen dürfen, können Sie sie auch nicht mehr einfach mit geschweiften Klammern {...} befüllen. Sie können nicht Rect r{1,2}; oder Rect s{6,2,3}; — durch das Packen von area_ in den privaten Bereich der Klasse ist Wert-Initialisierung für Rect unmöglich.

Sie benötigen also auf jeden Fall einen Konstruktor. Wir akzeptieren niemals, dass etwas nach der Definition uninitialisiert herumliegt! Das sieht der Compiler zum Glück auch so und daher generiert in diesen Fällen einen Konstruktor, nämlich den ohne Parameter. Dadurch können (und sollten) Sie zumindest Rect t{}; verwenden.

Und was macht dieser generierte Konstruktor? Effektiv initialisiert er Ihr Objekt mit Nullen, bzw. bei Membervariablen komplexerem Typs einem passenden Äquivalent.

Durch so viel Automatismen muss man erst einmal durchsteigen. Denken Sie auch an die Leser Ihres Programms und liefern Sie auch einen Konstruktor mit, und sei es nur der Konstruktor ohne Parameter. Andererseits, wenn der ohnehin nur tut, was der Compiler auch generieren würde, dann können Sie dessen Erzeugnis mit =default anfordern — dann haben Sie es wenigstens explizit gemacht und der Leser sieht direkt >>achja, Initialisierung ohne Parameter.<<.

class Rect {
    int area_;  // private Daten
public:
    int x_, y_;
    void set(int x, int y) { x_=x; y_=y; area_=x_*y_; }
    int calc() { return area_; }
    Rect() = default;  // Compiler Konstruktor generieren lassen
};
class Pow {
    int result_;  // private Daten. hält 'base' hoch 'exp'.
public:
    int base_, exp_;
    void set(int b, int e) { /* ... */ }
    int calc() { return result_; }
    Pow() : result_{1} {}  // base_, exp_ wurden 0, dann muss result_=1 werden.
};

Während Rect() = default; nur die Null-Initialisierung anfordert, die der Compiler sowieso eingesetzt hätte, macht der Konstruktor Pow() tatsächlich etwas: Da base_ und exp_ Null-Initialisiert wurden, muss result_ auf 1 gesetzt werden, denn 0^0=1.

Mal was ganz anderes. Wöchentlich bekomme ich von Linkedin Mails, wie folgt:

Torsten,

Congratulations! Your connection Xyz Abc has endorsed you for the following skills and expertise:

Perl

Zugegeben, ich habe mein Profil vor ca 11 Jahren dort erstellt, als ich aus der Bioinformatik (Perl-lastig) heraus einen neuen Job suchte, aber wir wissen ja: Das Internet vergisst nie.

Ja, Perl habe ich mal gemacht, ja ich kann Perl-Programme lesen und zur Not auch erweitern, ja, darum steht da Perl. Nicht dass ich da besonders storlz drauf bin, auch egal ob ich jemals wieder Perl anfassen möchte oder nicht — es steht da.

Schade nur, dass von meinen Kollegen damals niemand wusste, dass ich seit jeher viel lieber (und besser) C++ mache, aber wahrscheinlich mehr „hinter den Kulissen“. Und die noch älteren Kollegen wissen nicht, dass ich vor 12 Jahren zu Python gewechselt bin — in gewissen Kreisen scheinbar nicht so verbreitet, seltsamerweise ;-).

Sagen wir ich habe o.B.d.A. 100 nette Kollegen und Ex-Kollegen…. dann kann ich jetzt zu 90% Perl, zu 50% Python und zu 5% diese extrem esoterischen Sprache… uh, wie heißt die noch? Achja… C++.

Hach, das Internet funktioniert einfach nicht.

/schmunzel
/rant.

Markdown Support auf cpp11.generisch

Mit Markdown Support beim Editieren sollte Code wie main
sich leichter darstellen lassen.

## Markdown Support

Mit Markdown Support beim Editieren sollte Code wie `main`
sich leichter darstellen lassen.

    int main() {
        return 0;
    }

Das ist der Test dazu.

Das ist der Test dazu.

0

Posted on by

0

Effective C++11 — Scotts erste Ideen

Posted on by

Scott Meyers hat erste Ideen zu seinen Empfehlungen für ein potentielles Effective C++11.

Einige Kandidaten findet man indirekt auch in C++11 programmieren

  • „Prefer auto to Explicit Type Declarations“ — die Vorteile werden in [typeinfer.auto] besonders beschrieben, aber auch an vielen anderen Stellen
  • „Prefer non-member begin/end to member versions“ — Ausführlich in [syntax.for] besprochen
  • „Be Wary of Default Capture Modes in Lambdas Escaping Member Functions“ — Thema in [lambda.args]
  • „Pass std::launch::async if Asynchronicity is Essential“ — wird in [thread.async] erwähnt
  • „Distinguish Rvalue References from Universal References“ — Der Unterschied zwischen & und && wird in [rval.intro] besprochen.
  • „Prefer Lambdas over Binders“ — die Vorteile stehen auch in [func.funcobjs]
  • „Apply std::forward when Passing Universal References“ — ausführlich in [rval.forward] erklärt
  • „Prefer std::array to Built-in Arrays“ — wird in [stl.algorithm] angerissen
  • „Use std::make_shared Whenever Possible“ in [stl.shptr] begründet
  • „Reserve noexcept for Functions with Wide Interfaces“ — auch empfohlen in [std.noexcept]
  • „For Copyable Types, View Move as an Optimization of Copy“ — angerissen in [class.delete]
  • „Prefer enum classes to enums“ — begründet mit Beispielen in [enum.typed]
  • „Prefer nullptr to NULL and 0 — exakt wie in syntax.nullptr beschrieben

Ich freue mich jedoch darauf, wieder eine exzellente Zusammenfassung und Begründung von Scott Meyers in den Händen zu halten!