= ein: return n<=2 ? 1 : fib(n-2)+fib(n-1)wert>0 oder besser eine Überprüfung des Sonderfalls n==0 in berechne(int n).map<string<,vector<int>>main wird die aber bei opf.return reset(nullptr)…”Base *p = new Base Derived {}“return Thing(forward<T>(t), forward<TU>(u), forward<TV>(v));“data_ copyOnly_ nicht verschiebbar ist.” (der Fettdruck in Listing 23.9 ist korrekt.)string und dequeue…”mem_func_ref…”string ~~ist~~ [erlaubt]{.underline} das ~~für den~~ [dem]{.underline} Benutzer ~~transparent~~ [eine wie gewohnte Verwendung]{.underline}.”ratio<64,12>::den == 12 3“min1 stehen =“string-Bibliotheksfunktionen to_string und stoXX-Varianten werden erklärt (XX aus i, l, ll, etc.).fma, llround, etc.inline namespaceget_money(), put_money(), get_time() und put_time()/size()` sollte erst nach double gecastet werden.if(!cin) { muss sein if(!std::cin) {.#include#include <ifstream>if(groesstes !== nullptr) tun. Das kann man aber zu if(groesstes) abkürzen.”new ein, um das Objekt auf dem ~~Stack~~ [Heap]{.underline} zu erzeugen.”haello ist drei Zeichen lang....”difference distance aus…”std::visit für std::variant (C++17)Seite 50: #include, da fehlt das “l”.
Im Buch steht in Listing 14.1, Seite 207:
Zeile 12: int count = 0 // am EOF wird noch ein Wort gelesen
Zeile 18: return count - 1;
wobei im Beispiellisting 28-codes.cpp aber steht
Zeile 12: int count = -1 // am EOF wird noch ein Wort gelesen
Zeile 18: return count;
Beides ist korrekt, nur anders formuliert.
iota kommt aus dem Header numeric, nicht algorithm.
#include <array>
#include <algorithm>
#include <numeric>
! bindet stärker als >>. An dieser und anderen Stellen muss der boolsche Teilausdruck geklammert werden:
if(!(std::cin >> variable)).
// raus aus innerer xy-Schleife
Hätten Sie bei
cout << prod// Ziel von break ein break eingebaut, dann würde jedoch die x-Schleife verlassen und bei cout << "\n" fortgefahren.
Weil aber die arrSPAET -Definition nach der Verwendung steht,
Hier fehlt der Stream als Parameter (oder die globale Variable). Außerdem sind meine internen Prüfkommentare “//=” hineingerutscht (Auszeichnung des Listings als C++-Programm verkehrt).
//... Basis2 und Wert2 wie gehabt ...
void ausgabe(Basis2 x, ostream& os) {
// Übergabe als Wert
x.print(os);
}
int main() {
Basis2 ba2{}; ausgabe(ba2, cout); // gibt 8 aus
//= 8
Wert2 we2 {}; ausgabe(we2, cout); // gibt auch 8 aus
//= 8
}
dann hätte
ausgabe(we2) die ~~11~~[10]{.underline} ausgegeben
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.
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)orfor (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
thanT&&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…
…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).
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.
Habe soweit das Programm modern102.cpp in Visual Studio 2012 übernommen. Wenn ich das Prgramm ausführen lassen möchte, bekomme ich als Fehlermeldung:
error C2601: ‘table’: Lokale Funktionsdefinitionen sind unzulässig
Mir wird genau an der Stelle:
…static std::map\<int, int> table{};…
bei der geschweiften Klammer angezeigt, dass was nicht stimmt. Bei genaueren Hinsehen in Ihrem Buch, stehen unter den beiden geschweiften Klammern {} jeweils ein Punkt.
Das klingt sehr danach, dass der Compiler C++11-Konstrukte zurückweist.
Hier sehen Sie
dass “Visual Studio 2012” zum Beispiel die “Initializer Lists” nicht kennt, also die
Initialisierung mit “{…}”. Das ist hier das Problem.
Im Anhang können Sie alternative Schreibweisen für C++11-Konstrukte finden, die Ihr Compiler nicht kennt. Konkret schreiben Sie statt
static std::map<int, int> table{};
in MSVC2012:
static std::map<int, int> table;
Wenn Sie die Möglichkeit haben, sollten Sie auf die neueste Version von Visual Studio wechseln. Wenn nicht, müssen Sie teilweise auf alternative Schreibweisen ausweichen.
Möglicherweise hilft auch ein kleines Update, das habe ich aber nicht selbst probiert.
In early November 2012, Microsoft announced the Visual C++ Compiler November 2012 CTP, which adds more C++11 functionality to Visual Studio 2012.
Im buch können Sie Punkte unter den Klammern sehen, die auf ein C++11-Feature hindeuten (wird in Abschnitt 1.2, “Verwendete Formatierungen”, S. 27, eingeführt). Wenn an solchen Stellen etwas schief geht und der Compiler meckert, sollten Sie skeptisch werden. Hier ist die “Initialisierungsliste” gepunktet unterstrichen – weil “{}” so wenig Text ist, erschient diese Linie als nur zwei Punkte.
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:
if(value.equals("Wert"))` ersetzt if("Wert".equals(value))try { block } catch(...) { handler } alles fängt.{-Klammer noch auf die Zeile des ifs geschrieben wirdHier 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…
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.
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?”.
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.
Soso, da gibt es also ein neues Buch vom Erfinder: A Tour of C++, Bjarne Stroustrup.
Ich habe viele Stimmen gehört, die sein Standardwerk zum C++-Standard gut fanden, aber vielleicht war ich damals einfach zu früh.
Ein schneller Blick in sein neues – viel schlankeres – Werk ist nach meinem Geschmack: Viel Überblick, einige Details. Ein wenig vermisse ich die Zusammenhänge und wie die Sprachelemente vernetzt verwendet werden, aber wie gesagt, es war bisher nur ein schneller Blick, ich werde das prüfen. Ich denke zu dem Preis und der “Dünne” macht man nichts falsch.
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&) aufb = temp; – ruft noch einmal den Zuweisungsoperator Typ& operator=(const Typ&) auf.temp später per Destruktor weggeräumt.Bei diesem Prozedere gibt es vor allem zwei Dinge zu beachten:
Typ hält, werden diese wegen des Copy C’tors einmal kopiert.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.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.
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.
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.
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.
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.
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”.
dynamic_cast und keine dynamischen Exceptionsspezifikationen throw(...)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.usings und keine Nested Namespaces.operator int() besser int getInt().explicit sein. Auch dies vermeidet überraschende Konvertierungen.class und struct sind konzeptionell zu unterscheiden.private._” enden, also zum Beispiel data_.this verwenden, also zum Beispiel this->data_ (oder natürlich dem Getter).Das kann als Anregung für eigene Konventionen dienen.
Natürlich wird es nicht 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.
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
[typeinfer.auto] besonders beschrieben, aber auch an vielen anderen Stellen[syntax.for] besprochen[lambda.args][thread.async] erwähnt& und && wird in [rval.intro] besprochen.[func.funcobjs][rval.forward] erklärt[stl.algorithm] angerissen[stl.shptr] begründet[std.noexcept][class.delete][enum.typed]syntax.nullptr beschriebenIch freue mich jedoch darauf, wieder eine exzellente Zusammenfassung und Begründung von Scott Meyers in den Händen zu halten!
…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.
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.
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…
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:
sqrtrem()` um gleichzeitig Quadratwurzel und Rest zu erhaltenpow(), 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.Chancen sich einzubringen hat man vielleicht insbesondere bei den noch offenen Punkten des aktuellen Vorschlags:
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?integer in einen int umgewandelt werden soll?Wer hat Vorschläge?