C++1y

C++1y, der Nachfolger con C++11

0

class X : public Y ist böse — concepts lite, gut?

Posted on by

Hier wird argumentiert, dass in Java extends „böse“ ist.

Während die Formel „ist böse“ natürlich zu einfach ist, stimme ich der Argumentation jedoch zu und ich finde es schön begründet. Mal weniger theoretisch als auch schön an praktischen Beispielen.

In C++ entspricht das wohl dem, dass man besser type traits statt Vererbung verwendenden sollte. Ich sollte den Artikel mal versuchen, nach C++ zu übersetzen. Auf die Schnelle kann ich nur sagen, dass es ja in C++ keine wirklichen Interfaces gibt wie in Java, die man mit „implements“ in seinen Klassen verwenden würde. In C++ ist es sehr wenig verbreitet mit puren „Signatur-Klassen“ zu arbeiten (alle Methoden abstrakt, i.e. pure virtual). Daher kommt dem „implements“ von Java in C++ der Weg über Typparameter von Templates am nächsten, i.e. type traits.

Aber eben nicht komplett, „implements“ kann mehr — lesbare Fehlermeldungen zum Beispiel. Und unter anderem deshalb erwarten wir alle Concepts Lite

5

Swap-Operator?

Posted on by

Manuelles Swap

Elemente zu vertauschen ist an vielen Stellen eine gefährliche Operation. Zu Zeiten ohne Exceptions und ohne Multithreading war vertauschen noch einfach:

Typ temp = a;
a = b;
b = temp;

Aber was passiert hier genau:

  • Typ temp = a; — erzeugt eine neue Instanz und initialisiert sie mit a, per Copy ConstructorTyp(const Typ&).
  • a = b; — ruft den Zuweisungsoperator Typ& operator=(const Typ&) auf
  • b = temp; — ruft noch einmal den Zuweisungsoperator Typ& operator=(const Typ&) auf.
  • Weil es eine neue Instanz ist, wird temp später per Destruktor weggeräumt.

Problempunkte

Bei diesem Prozedere gibt es vor allem zwei Dinge zu beachten:

  • Die Ressourcen, die Typ hält, werden diese wegen des Copy C’tors einmal kopiert.
    • Schade, wenn dies zum Beispiel ein riesengroßer Speicherblock ist, zu dem vielleicht nur ein Pointer getauscht werden müsste
    • Manche Resourcen können nicht kopiert werden: Locks, Mutexe, Filehandles machen Probleme, etc. Dann funktioniert das ganze Vorgehen nicht.
  • Was, wenn b = temp eine Exception wirft? Der Zuweisungsoperator sollte das nicht, aber wenn man dessen Code nicht unter Kontrolle hat? Dann sind a und b nicht vertauscht, sondern identisch. Das alte a ist verloren.

Der bessere Weg

Daher wird seit jeher die Verwendung der swap-Funktion aus der Standardbibliothek empfohlen:

using std::swap;
swap(a, b);

oder seit C++11 auch einfach

std::swap(a, b);

denn die Namensauflösung der swap-Implementierung wurde leicht geändert (Details im Buch 😉 oder bei Stackoverflow).

Edit: Es ist ein Idiom, die swap-Funktion eine friend-Memberfunktion zu machen, auch dazu mehr bei Stackoverflow.

Auch swap soll — wie der Zuweisungsoperator (und andere Beteiligte) — keine Exceptions werfen. Und da für die swap-Implementierung empfohlen wird, die Member elementweise wieder mit swap zu vertauschen, würde statt der Kopie der Ressourcen * im Falle des großen Datenblocks nur der Pointer ge-swapped * im Falle der nicht-kopierbaren Ressource diese vertauscht, was gehen sollte.

Daher merke (seit jeher): Eigene Datentypen sollten swap implementieren.

Neuer Operator :=:

Um die Wichtigkeit von swap zu unterstreichen, gibt es den Vorschlag, swap als Operator :=: einzuführen. Das sähe dann so aus:

struct Typ {
    Data a;
    Feld b;
};
Typ& operator:=:(Typ& lhs, Typ& rhs) noexcept {
    lhs.a :=: std::move(rhs.a);
    lhs.b :=: std::move(rhs.b);
    return lhs;
}
Typ& operator:=:(Typ& lhs, Typ&& rhs) noexcept {
    return rhs;
}

Statt nacheinander die Elemente mit swap zu vertauschen verwendet man den neuen :=:-Operator. Beziehungsweise die &&-Variante, die für das swappen mit der rhs-Instanz da ist, die ohnehin bald weggeworfen würde gestaltet sich die Implementierung besonders leicht: Nimm als lhs einfach rhs.

Dadurch ist hervorgehoben, dass es sich um eine sehr spezielle Funktion handelt, und kommt somit namenstechnisch dem operator= näher. Der Benutzer wird eher darauf gestoßen, dass er sie implementieren sollte.

Es gibt nich weitere kleine Ergänzungen für :=:, zum Beispiel für die eingebauten Typen.

Glaskugel

Hauptsächlich handelt es sich um eine Sytnax-Erweiterung mit nur wenig funktionalen Ergänzungen. Meine Vorraussage ist, dass dieses Feature es nicht in den Standard schafft. Wenn es nur um Syntax geht, war das Kommitee eher zurückhaltend.

Was für ein Überseher! Da gibt es die wichtige und nützliche Funktion make_shared() um einen shared_ptr ssicher zu erzeugen, und in dem ganzen Trubel um die Fertigstellung von C++11 wurde das Pendant make_unique() übersehen. Das lässt sich zum Glück leicht korrigieren und die meisten C++11-konformen Compiler sollten mit dieser Bibliothekskorrektur mitgeliefert werden. In C++14, was auf dem besten Weg ist, ist es dann enthalten.

0

Posted on by

0

C++ Networking als Teil des Standards

Posted on by

Natürlich wird es nich ein paar Jahre dauern bis aus der Ankündigung, dass eine Arbeitsgruppe die Arbeit aufnimmt letztlich ein Standard wird, aber es geht vorwärts.

Im Oktober will die Study Group 4 Ideen zur Standardisierung zur Netzwerkprogrammierung vorstellen: IPv4 und IPv6-Adressen, Adressen auflösen, Ports und URIs, Datagramm- und Netzwerk-Streams sowie ein erstes SSL-Interface. Auf dieser Basis sollen dann später höhere Protokolle wie HTTP und FTP aufgesetzt werden.

Bis dahin bittet die Gruppe um die Einreichung von Vorschlägen für ein Socket Interface, das zum Standard werden könnte.

0

Mit C++11 hört C++ nicht auf — unbounded-precision integer types

Posted on by

Mit der Verabschiedung von C++11 gibt sich die Gemeinde natürlich nicht zufrieden. Auch C++ wird sich natürlich noch weiter entwickeln. Einige Dinge wurden aus C++0x herausgelassen, damit „0x“ es letztendlich wenigstens „11“ werden konnte. Man wird aber sicher alte Bekannte irgendwann wiedersehen.

Dazu gehören zuvorderst natürlich die Concepts, aber viele erwarten auch Asynchrone IO oder Filesystem- und Dateinamenbehandlung — oder irgendetwas aus dem Umfeld von Boost.

C++1y, TR, oder Papierkorb

Was in den Standard Einzug halten wird, ob wann, oder ob es einen Nachtrag oder Technical Report mit Erweiterungen geben wird, steht natürlich in den Sternen. Nein, nicht in den Sternen — man kann sich an den Diskussionen ja beteiligen und vielleicht deren Ausgang ein wenig beeinflussen. Für den Interessierten lohnt es sich also, die Augen offen zu halten…

Es tut sich viel, aber ich greife mal exemplarisch etwas heraus…

integer und unsigned_integer

Neu in der Diskussion ist eine kleine aber feine Erweiterung für Ganzzahlen mit unbegrenzter Genauigkeit. „Unbegrenzt“ meint hier dynamisch unbegrenzt, im Vergleich zu statisch unbegrenzt. Es wäre ein wenig leichter, zum Beispiel einen Zahltypen zu definieren, bei dem man bei der Initialisierung eine maximale Länge angeben muss — überschreitet man die, gäbe es einen Überlauf. Statt aber die Klasse integer auf einer Art festem Array zu basieren, schwebt den Autoren von N3375 konzeptionell eher ein vector vor. So kann kein Überlauf mehr passieren, die Größe passt sich automatisch an — bis der Speicher ausgeht…

Da gibt es natürlich schon jede Menge Bibliotheken (zum Beispiel die vielseitige Gnu GMP), aber die wenigsten schmecken nach C++11.

Mit den bestehenden Zahlentypen wird integer natürlich interagieren. Die arithmetischen wie +, * und Verwandte werden mit sich selbst und int-Varianten unterstützt.

    integer i = 30000;
    integer j = 1000 * i;

Allerdings geschieht dies im aktuellen Vorschlag nicht durch Überladung von operator+() etc mit allem möglichen int-Varianten, sondern durch die implizite Umwandlung von int in integer.

Der aktuelle Vorschlag bietet:

  • arithmetische Operationen +, -, *, /, %, — und ++
  • eine Funktion div(), die gleichzeitig das ganzzahlige Ergebnis und den Rest zurückgibt,
  • Bitoperationen |, &, ^, <<, >>, <<=, >>=, |=, &= und^=.
  • Vergleiche ==, <, >, !=, <= und >=
  • Quadrat, Quadratwurzel sowie `sqrtrem()` um gleichzeitig Quadratwurzel und Rest zu erhalten
  • Exponenzieren mit pow(), bzw. powmod() — letzterest ist ein häufiger Anwendungsfall, der eine platzsparendes pow() gefolt von einer Modulo-Operation ist. Den GGT und KGV kann man mit gcd() und lcm() berechnen.
  • Eine beliebig lange Zufallszahl kann man erstellen,
  • Stream-Ein- und Ausgabe wird unterstützt; mit `to_string(base=10)` ist ebenfalls praktisch.

Noch Offen

Chancen sich einzubringen hat man vielleicht insbesondere bei den noch offenen Punkten des aktuellen Vorschlags:

  • Wie soll die Speicherverwaltung duch den Benutzer beeinflußt werden können? Wie sollen Allocators Eingang finden?
  • Was soll passieren bei einem Unterlauf, zum Beispiel bei
    • unsigned_integer neg = -99;?
    • unsigned_integer five = 5 und dann unsigned_integer result = five - 100?
    • unsigned_integer five = 5; unsigned_integer ten = 10, dann five - ten?
  • Wie ist mit Präzisionsverlust umzugehen, wenn ein sehr großer integer in einen int umgewandelt werden soll?

Wer hat Vorschläge?

Links

N3375 – Proposal for Unbounded-Precision Integer Types