K
shreadder schrieb:
Aufbauend auf diesem Blogpost von einem bekannten C++-Guru: http://bartoszmilewski.com/2013/09/19/edward-chands/
Den einen oder anderen seiner Blogartikel habe ich wohl gelesen, auch die zwei, die er hier im Abschnitt zur Nebenläufigkeit referenzierte ("broken promises", "task based parallelism"). Aber irgendwie finde ich davon kaum etwas überzeugend. Seine Seite flog dann irgendwann aus meinem Feed-Reader raus.
Bei diesem neuen Artikel werde ich das Gefühl nicht los, als würde er übertreiben, als würde er hier und da Äpfel mit Birnen vergleichen. Z.B. hier:
D at least has the notion of deep constness [...] But C++ doesn’t support any of this [...]
Was habe ich daran auszusetzen? Er erwähnt "deep constness" als sei das ein Feature, welches in C++ fehle. Dabei ist "deep constness" in D der Versuch, Komposition trotz aufgezwungene Indirektion zu emulieren. Komposition wird in C++ aber direkt unterstützt. In C++ haben wir diese drei Objekt<->Objekt beziehungen:
Objekt A betitzt Objekt B. Objekt B ist Subobjekt von A (ein Teil davon). Hier verhält sich const genauso, wie man es will.
Objekt A kennt Objekt B über einen Zeiger. B ist nicht Teil von A. Warum sollte sich die constness von A an B übertragen? Denken wir zB. an Iteratoren.
Objekt A besitzt Objekt B, aber nur die Adresse von B ist Teil von A. Das kann nützlich sein (B könnte optional oder polymorph sein) Hier muss man eh Hand anlegen: Kopierkonstruktor/Zuweisungsoperator deaktivieren oder selbst implementieren, Destruktor schreiben. Da tut es zwecks Kapselung auch nicht weh, wenn man einen Accessor anbietet, der sich um Constness kümmern (wie z.b. operator[] bei std::vector).
"deep constness" bei Zeigern ist eher unnütz, wenn man sie einfach Kopieren kann:
struct foo
{
deep_const_ptr<int> ptr;
};
void foo(const foo& f)
{
// *(f.ptr) ist ein const int Lvalue
foo g = f;
*(g.ptr) = 42; // oops! das geht ja sogar!
}
Sorry, ich werde das Gefühl nicht los, dass die, die sich über das Fehlen von "deep constness" bei C++ beklagen, nicht klar im Kopf sind. Alexandrescu hat da auch schon komische Kommentare in comp.lang.c++ gelassen, wo ich mich fragen muss, ob er "const" eigentlich verstanden hat. (Er wollte mal const-Überladungen für Konsruktoren haben).
shreadder schrieb:
std::async und std::future völlig broken,
Kannst du bitte zusammenfassen, was daran "völlig broken" ist?
shreadder schrieb:
std::mutex/std::thread/std::condition_variable sind viel zu lowlevel um sie sinnvoll einsetzen zu können
Wo ist das jetzt ein Argument für die "Unvereinbarkeit" von C++ mit "moderner Parallelisierung"? Willst Du behaupten, dass man da nicht drauf aufbauen kann?
shreadder schrieb:
Keinerlei Schutzmechanismen in der Sprache gegen Data Races u.Ä. (pure, immutable)
Das ist mir persönlich ein bisschen zu abstrakt. Am besten erklärst du mir das mal mit schönen Beispielen.
shreadder schrieb:
Daher sind STM, Tasks, etc. praktisch unmöglich sinnvoll umzusetzen un
d C++ ist ungeeignet für modernes Threading
Mit STM kenne ich mich zu wenig aus, als dass ich dazu was sagen kann. Das mit den Tasks lasse ich mir ja von dir nochmal erklären.
