Leserbriefe April 2021

Fehler bei Codewiederholungen

(Programmierung: Clean Code mit C++20, Teil 1: Effizientere Vergleiche; iX 3/2021, S. 152)

Nachdem ich gestern die Märzausgabe der iX erhalten hatte, habe ich gleich als ersten den C++-Artikel angesteuert. Sicher wollen Sie die Aufmerksamkeit Ihrer Leser testen. Mit dem Listing 6 haben Sie gleich ein Beispiel gezeigt, wie schwierig es ist, korrekten Code zu schreiben, wenn man zu Wiederholungen gezwungen wird. Weniger Quelltextzeilen sind mehr.

Als Erstes springt die Definition des Kleiner-als-Operators mit

return
(x < rhs.x) && (*_x_* < rhs.*_y_*);

oder etwas umformuliert

return x <std::min(rhs.x, rhs.y); 

ins Auge. Möglicherweise war doch

return (x < rhs.x) && (*_y_* <rhs.*_y_*); 

gemeint. Wird rhs in den Koordinaten­ursprung transformiert, bleibt bei diesem Vergleich nur ein Quadrant übrig. In allen anderen Quadranten wäre *this größer. Ich würde den Operator wie folgt definieren:

return x< rhs.x || x==rhs.x&& y< rhs.y; 

Damit gibt es genauso viele Punkte, die kleiner rhs, wie die, die größer sind. Besser gefällt mir aber der Trick, den ich in einem Ihrer letzten Artikel gelesen hatte:

return std::tuple{ x, y } < std::tuple{ rhs.x, rhs.y }; 

Der Compiler kürzt sicher die temporären Konstruktoren wieder heraus. Das entspricht auch der Version, die automatisch generiert wird.

Die beiden Varianten <= und >= scheinen plausibel, aber beide greifen auf die ungewollte Implementierung des Kleiner-­als-Operators zurück. Automatisierte Tests hätten dann ihre Schwierigkeit, Fehler zu detektieren, die der Standardlogik widersprechen. Der Größer-als-Operator wird als not(*this < rhs) beschrieben. Wenn etwas nicht kleiner als x ist, ist es größer oder gleich x.

constexpr bool *>= *operator(const Point& rhs) const noexcept      {
  return not( *this < rhs); }

Die übrigen Operatoren würde ich z. B. in der folgenden Art deklarieren:

constexpr bool *<= *operator(const Point& rhs) const noexcept      {
  return *this < rhs || *this == rhs; } 

und

constexpr bool *> *operator(const Point& rhs) const noexcept       {
  return not(*this<= rhs); }

Effizienter ist es, die Operanten zu tauschen – aber hier muss man wirklich konzentriert arbeiten, um nicht in eine Endlosrekursion zu laufen: 

constexpr bool *<= *operator(const Point& rhs) const noexcept      {
  return rhs >= *this; } 

und

constexpr bool *> *operator(const Point& rhs) const noexcept       {
  return rhs < *this; }

Ich glaube aber, dafür gibt es eine Implementierung in der STL. Dann braucht man sich auch nicht mehr darum kümmern, welche Variante weniger Prozessortakte verbraucht.

Neu war mir die Erkenntnis, dass der Compiler logische Äquivalenzen in C++20 selbst herleitet und so zum Beispiel unterschiedlich typisierte Operanten vertauscht. strong~, partial~, weak_ordering sowie die default-Operatordeklaration waren mir ebenfalls neu. Eine Revision unseres Quelltextes wird sicher einigen nun unnötigen Ballast zutage fördern, der mit C++20 entsorgt werden kann. Alles in allem ein großer Erkenntnisgewinn. Ich freue mich auf die nächste Ausgabe!

Thomas Haenel, via E-Mail

Ich teste durchaus gelegentlich mit solchen Dingen die Aufmerksamkeit oder nutze sie als Argumente für Clean Code. Aber nur dann, wenn ich es auch richtigstellen kann. Hier haben Sie einen echten Fehler gefunden. Vielen Dank!

Ihr Ansatz ist ein guter. Für mich ist es in Artikeln immer schwer abzuschätzen, was für Elemente ich ohne zusätzliche Erklärung verwenden kann und welche besser nicht. Zu viel extra Erklärung für z. B. Tupel lenkt von meinem eigentlichen Punkt ab. Produktivcode sieht am Ende doch etwas anders aus, eher wie von Ihnen beschrieben. Auch Ihr Punkt mit den automatisierten Tests ist korrekt, denn meine eigenen Tests haben den Fehler ebenfalls nicht erkannt. Allerdings sind diese für Artikel meist rudimentär.

Dass der Compiler logische Äquiva­lenzen in C++20 selbst herleitet, ist in der Tat ein Teil des Spaceship-Operators, der weniger bekannt ist. Der Operator-Re­write ist im Standardisierungskomitee nicht unumstritten. Gerade beim Portieren einer existierenden Codebasis kann es zu Überraschungen kommen. Ich will damit nicht sagen, dass der Operator-Re­write schlecht ist. Es wäre einfach besser gewesen, diesen nur stattfinden zu lassen, wenn ein Spaceship-Operator definiert ist oder die Vergleichsfunktionen mit =default markiert wurden. Damit wäre Prä-C++20-Code „einfacher“ nach C++20 portierbar, weil sich dann das Verhalten nicht von selbst ändert. Leider war die Mehrheit anderer Meinung. (Andreas Fertig)

Schutz von Geschäftsgeheimnissen

(Markt + Trends: IT-Recht & Datenschutz; iX 3/2021, S. 30)

Zum Artikel „Kriterien für den Geheimnisschutz“ eine Frage: Wie lautet das Aktenzeichen des Urteils, über das hier berichtet wird? Das wäre durchaus hilfreich, wenn man sich näher mit dem Thema beschäftigen möchte.

Marcus Ohlhaut, via E-Mail

Vielen Dank für das Interesse, das Aktenzeichen lautet: OLG Stuttgart, Urt. v. 19.11.2020 – Az. 2 U 575/19

Künstliche Intelligenz fehlt

(Systemmanagement: Marktübersicht Application Performance Monitoring; iX 03/2021, S. 80)

Ich finde es schade, dass der Artikel nur oberflächlich den spannendsten Aspekt der Werkzeuge angeht, nämlich die AI-Ops. Als Dienstleister in Paris setze ich mehrere dieser Werkzeuge bei Großkunden ein, und gerade bei Dynatrace erzielen wir mit der KI verblüffend gute Ergebnisse. Die KI ist dermaßen genau, dass wir inzwischen bei einem großen Versicherungsunternehmen quasi prädiktiv Produktionsausfälle ankündigen, bevor die Endbenutzer sich melden. Hier hätte der Artikel die Anbieter in zwei verschiedene Kategorien aufteilen können, Leading Edge oder traditionelles Monitoring.

Pascal Specht, via E-Mail

Die iX-Redaktion behält sich Kürzungen und auszugsweise Wiedergabe der Leserbriefe vor. Die abgedruckten Zuschriften geben ausschließlich die Meinung des Einsenders wieder, nicht die der Redaktion.