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

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

GCC C++ Coding Guidelines als Guideline?

Posted on by

Der GCC hat nun eine C++-Implementierung für alle drei Compilerphasen.
Da lohnt es sich mal einen Blick darauf zu werfen, was Gnu von C++ alles nutzen möchte. C++ ist nunmal eine große Sprache und man muss sich in einem Projekt entscheiden, was man davon nutzen will.
Ich fasse mal ganz knapp die Wiki-Seite zusammen. Diese Konventionen haben aber noch recht wenig mit C++11 zu tun, weil „der aktuelle GCC sich immer mit der vorigen (stabilen) Version bauen lassen muss“.

Allgemeine und Dialekt-Regeln

  • Der Code muss sowohl C++03 als auch C++11 konform sein.
    Das liegt natürlich daran, dass eine vorige Version den neuen Compiler übersetzen können muss. In einem eigenen Projekt müsste man diese Regel nicht unbedingt verwenden.
  • Kein RTTI und somit kein dynamic_cast und keine dynamischen Exceptionsspezifikationen throw(...)
  • und (tadaaa:) keine Exceptions! Warum, das wird auch erwähnt: Im Moment ist der Großteil des GCC-Codes nicht Exception-Safe. Dass es gut wäre, den Code auf RAII umzustellen, wird aber auch erwähnt. Das ist jedoch extrem viel Aufwand. Dann wären Exceptions natürlich nötig.
  • Statt auto_ptr nur tr1::shared_ptr, denn ersterer sei defekt. Wenn man sich selbst für C++11 entscheidet, dann kann man wohl auch den C++11 shared_ptr verwenden.

Welche Features?

  • Keine neuen Templates einführen.
  • Keine usings und keine Nested Namespaces.
  • Statt Konversions-Operatoren immer explizite Methoden verwenden. Also statt operator int() besser int getInt().
  • Konstruktoren mit einem Argument sollten immer explicit sein. Auch dies vermeidet überraschende Konvertierungen.
  • Keine Mehrfachvererbung.
  • Copy- und Assignment-Operatoren sollten vermieden werden, sind aber o.k. für pure Werteklassen. Der Grund ist, dass der Compiler selbst brauchbare Versionen generiert, wenn die Klasse keine Pointer enthält. Und wenn sie das tut, dann soll man sicherheitshalber Copy und Assign verbieten. Das führt langfristig dazu, dass Entwickler weniger Raw-Pointer verwenden werden.

C++ Konventionen

  • class und struct sind konzeptionell zu unterscheiden.
  • Konstruktoren sollen alle Datenfelder in ihrer Initialisierungsliste setzen.
  • Alle Datenfelder von Klassen sind private.
  • Namen von Datenfeldern sollten mit einem „_“ enden, also zum Beispiel data_.
  • Methoden sollten diese Datefelder dann mit this verwenden, also zum Beispiel this->data_ (oder natürlich dem Getter).

Das kann als Anregung für eigene Konventionen dienen.

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.

Angenommen jemand schreibt ein Buch. Natürgemäß sind in dem Buch ein paar Fehler und man habe nur nette Leser, die Fehler finden und für die 2. Auflage mitteilen.

Der Einfachheit halber sind hier mal alle Fehler gleich schwer zu entdecken (als Wahrscheinlichkeit gesprochen: Es ist gleich wahrscheinlich den einen oder den anderen Fehler zu finden).

So trudeln nette Leserkommentare mit Hinweisen auf Fehler ein. Irgendwann wird ein Fehler das zweite Mal genannt werden.

Was kann man als Schätzung über die Anzahl der Fehler in dem Buch aussagen, wenn die siebte Meldung das erste Mal einen Fehler das zweite Mal beschreibt?


In den Kommentaren ist Platz für Lösungen und Diskussionen 😉


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!

1

Schrödinger programmiert C++

Posted on by

…Das etwas andere Lehrbuch (Galileo Computing)

Ich kann dieses Buch sehr empfehlen.

Es liefert einen guten Einstieg in C++.

Es ist locker geschrieben, bleibt aber dennoch bei den Fakten. Es bringt die C++igen Konzepte durchaus herüber, ist jedoch nicht dogmatisch. Der Leser wird auch nützliche C’ismen erlernen, aber meist mit dem Hinweis, dass es sich hierbei um „gutes altes Tse“ handelt. Am anderen Ende der Skala kommt auch C++11 nicht zu kurz.

Das Buch ist auch noch aufwendig farbig produziert, ein Augenschmaus und Schmuck auf dem Schreibtisch.

Externe Links

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

1 2