C++11-Buch gesucht

SeppJ

stdexcept schrieb:

Und was passiert dann mit der Message?

Sie wird gelesen. Weil sie nützlich ist.

SeppJ schrieb:

stdexcept schrieb:

Und was passiert dann mit der Message?

Sie wird gelesen. Weil sie nützlich ist.

Von wem?

SeppJ schrieb:

Ich schreibe die Fehlermeldungen nicht für Benutzer. Ich schreibe sie für mich.

Ah, der Benutzer schickt sie dir per Mail zu, wenn ein Fehler auftritt (und er muss auftreten, weil sonst gäbe es keinen Grund, nicht Assertions zu verwenden).

Aber der Benutzer bekommt sie trotzdem vor Gesicht. Vernünftige Softwarebetriebe würde solche Messages von UI-Experten anschauen und übersetzen lassen.

Nathan

asserts und Exception sind verschiedene Dinge!
assert() wird eingesetzt um bspw. bei operator[] zu prüfen ob i < size ist.
Exceptions werden eingesetzt, wenn der OpenGL Kontext nicht erstellt wurde.
Und wenn der Benutzer dann eine Messagebox vors Gesicht bekommt, wie z.B.:

Es ist eine Ausnahme aufgetreten. Fehler: "my::win::opengl_context::create: unable to create context" Bitte kontaktieren Sie das Supportteam.

, weiß der User was zu tun ist und die Supporter wo der Fehler liegt.

SeppJ

Schließ nicht von deinen DAU-Nutzern auf andere.

Schließ auch nicht von deiner "Erfahrung" als Anwendungsentwickler, dass alle Leute Endanwendersoftware schreiben.

Dein Horizont ist einfach schwer beschränkt, wenn du keine Nützlichkeit in nützlichen Meldungen siehst.

Sone

Ihr beide geht extrem Off-Topic. Splitte doch wenigstens den Thread, SeppJ.

Nathan schrieb:

asserts und Exception sind verschiedene Dinge!
assert() wird eingesetzt um bspw. bei operator[] zu prüfen ob i < size ist.
Exceptions werden eingesetzt, wenn der OpenGL Kontext nicht erstellt wurde.

Falsch. Asserts werden eingesetzt, wenn der Fehler so gravierend ist, dass das Programm nicht sinnvoll fortgesetzt werden kann. Exceptions sind dazu gedacht, wenn du Stack Unwinding zum nächsten sinnvollen State machen willst.

Du kannst z.B. ein assert() schreiben, das eine Messagebox aufmacht und anschliessend das Programm beendet.

"Es ist ein Fehler aufgetreten: "kontextersteller.cpp:42:13: create_context(): context!=NULL" Bitte kontaktieren Sie das Supportteam.

Exceptions haben da einfach keinen Mehrwert.

Schließ nicht von deinen DAU-Nutzern auf andere.

Wie wäre es, wenn du aufhörst, andere zu beleidigen und sachliche Argumente lieferst?

Schließ auch nicht von deiner "Erfahrung" als Anwendungsentwickler, dass alle Leute Endanwendersoftware schreiben.

Ich gehe davon aus, dass deine Software irgendwelche Kunden hat.

Dein Horizont ist einfach schwer beschränkt, wenn du keine Nützlichkeit in nützlichen Meldungen siehst.

Ich sehe sehr wohl eine Nützlichkeit in nützlichen Meldungen. Der Punkt ist nur, dass deine Meldungen nur für den Entwickler nützlich sind. Das kann auch assert().

Nützliche Meldungen mit Exceptions erreicht man durch

the proper use of a what() string is to serve as a key into a table of error message formatters

Nathan

stdexcept schrieb:

Nathan schrieb:

asserts und Exception sind verschiedene Dinge!
assert() wird eingesetzt um bspw. bei operator[] zu prüfen ob i < size ist.
Exceptions werden eingesetzt, wenn der OpenGL Kontext nicht erstellt wurde.

Falsch. Asserts werden eingesetzt, wenn der Fehler so gravierend ist, dass das Programm nicht sinnvoll fortgesetzt werden kann. Exceptions sind dazu gedacht, wenn du Stack Unwinding zum nächsten sinnvollen State machen willst.

Du kannst z.B. ein assert() schreiben, das eine Messagebox aufmacht und anschliessend das Programm beendet.

"Es ist ein Fehler aufgetreten: "kontextersteller.cpp:42:13: create_context(): context!=NULL" Bitte kontaktieren Sie das Supportteam.

Dumm nur, dass asserts im Release-Build gar nicht mehr auftauchen sollten!
Und ich denke es gibt nichts gravierenderes als einen SegFault.
Läuft ein Programm im Debug mit assert, läuft es auch im Release ohne assert.
Dinge wie "File not found" oder "not enough memory" oder "unable to create context", die abhängig vom User sind, werden mit exceptions gelöst.

SeppJ

stdexcept schrieb:

Dein Horizont ist einfach schwer beschränkt, wenn du keine Nützlichkeit in nützlichen Meldungen siehst.

Ich sehe sehr wohl eine Nützlichkeit in nützlichen Meldungen. Der Punkt ist nur, dass deine Meldungen nur für den Entwickler nützlich sind. Das kann auch assert().

Dann schreib nochmal an die Macher der Standardbibliothek, dass sie doch bitte ein assert in malloc/new einbauen sollen. Ach, macht keinen Sinn, obwohl nur Entwickler jemals eine bad_alloc zu Gesicht bekommen! Wer hätte das erwartet?

Wenn doch jetzt bloß bei einer "file not found"-Exception noch dabei stünde, welche Datei nicht gefunden wurde. Ach, tut es! Vollkommen nutzlos! Welcher Entwickler baut so etwas ein? Haben die wohl deine schlauen Sprüche nicht gelesen.

Wenigstens steht bei einem doppelten free oder heap corruption nicht dabei, an welcher Adresse der Fehler auftrat. Ach, tut es! Anscheinend hast du auf der Welt noch viel Überzeugungsarbeit zu leisten.

SeppJ schrieb:

Dann schreib nochmal an die Macher der Standardbibliothek, dass sie doch bitte ein assert in malloc/new einbauen sollen. Ach, macht keinen Sinn, obwohl nur Entwickler jemals eine bad_alloc zu Gesicht bekommen! Wer hätte das erwartet?

In bad_alloc steht kein schlaues what().

SeppJ schrieb:

Wenn doch jetzt bloß bei einer "file not found"-Exception noch dabei stünde, welche Datei nicht gefunden wurde. Ach, tut es! Vollkommen nutzlos! Welcher Entwickler baut so etwas ein? Haben die wohl deine schlauen Sprüche nicht gelesen.

Zumindest bei Boost wird die Meldung des Betriebssystems zurückgegeben und das wird übersetzt (auf Deutsch z.B.).
Dein Text wird das nicht, deshalb ist er nutzlos.

SeppJ schrieb:

Wenigstens steht bei einem doppelten free oder heap corruption nicht dabei, an welcher Adresse der Fehler auftrat. Ach, tut es! Anscheinend hast du auf der Welt noch viel Überzeugungsarbeit zu leisten.

double-free und heap corruption ist normalerweise ein assert.

Nathan schrieb:

Dumm nur, dass asserts im Release-Build gar nicht mehr auftauchen sollten!

Dumm nur, dass mich niemand daran hindert, verschiedene Arten von asserts zu schreiben. Das macht deine Argumentation hinfällig.

otze

stdexcept schrieb:

Dumm nur, dass mich niemand daran hindert, verschiedene Arten von asserts zu schreiben. Das macht deine Argumentation hinfällig.

an welcher stelle ds programms weißt du denn a-priori ob du ein debug doer release assert brauchst? Und wenn du das release assert ohne exception baust, werden dir die user die bude vollkotzen, weil das exit() verhindert das die Datenbank noch ordentlich geschlossen wird und sie jetzt eine inkonsistente Datenhaltung haben.

noch so tolle Ideen um einfach mal recht zu haben?

otze schrieb:

an welcher stelle ds programms weißt du denn a-priori ob du ein debug doer release assert brauchst?

Wenn es denkbar ist, dass es von aussen geändert werden kann und billig zu testen ist, dann ein Release-Assert.

otze schrieb:

Und wenn du das release assert ohne exception baust, werden dir die user die bude vollkotzen, weil das exit() verhindert das die Datenbank noch ordentlich geschlossen wird und sie jetzt eine inkonsistente Datenhaltung haben.

Das Release-Assert ist dazu da, mich vor inkonsistenten Zustand zu bewahren. Das Assert feuert genau dann, wenn die Datenbank in inkonsistentem Zustand ist. Das will ich nicht kontrolliert beenden und die Inkonsistenz noch weiter vergrössern, da will ich einfach raus.

Ein Release-Assert ist die Ausnahme!

Für alle anderen Fälle mit möglichen Fehlern sind Exceptions der richtige Ansatz, dann aber mit richtigen Fehlermeldungen . Das heisst the_file_that_wasnt_found ist nicht in der Message eingebettet sondern abfragbar, das heisst Message ist ein Formatstring aus einem Ressourcenfile.

Also nochmal zu den Büchern:

Die im zweiten Post genannten wirken auf mich zu überladen. Ich bin derzeit Anwender mit wenig Zeit, deswegen suche ich soetwas wie eine gute Referenz +ber C++11 in Buchform

SeppJ

C++-+-+ schrieb:

Also nochmal zu den Büchern:

Die im zweiten Post genannten wirken auf mich zu überladen. Ich bin derzeit Anwender mit wenig Zeit, deswegen suche ich soetwas wie eine gute Referenz +ber C++11 in Buchform

Ist denn da das Buch, das du schon hast, nichts für dich? Es enthält zwar kein to_string, aber sonst ist es doch ziemlich referenzartig und ziemlich komplett. Ich benutze mein Exemplar jedenfalls auf genau diese Art, wenn ich mal schnell die Syntax von etwas Neuem nachschlagen möchte. Ähnliches Buch:
http://www.c-plusplus.net/forum/309733

Sone

Ich benutze mein Exemplar jedenfalls auf genau diese Art, wenn ich mal schnell die Syntax von etwas Neuem nachschlagen möchte.

Nimm doch den Standard. Der ist doch direkt die Quelle.

SeppJ

Sone schrieb:

Ich benutze mein Exemplar jedenfalls auf genau diese Art, wenn ich mal schnell die Syntax von etwas Neuem nachschlagen möchte.

Nimm doch den Standard. Der ist doch direkt die Quelle.

Leseprobe bei Amazon schrieb:

Sie können das neue auto noch an anderer Stelle bei der Variableninitialisierung verwenden, nämlich in der neuen Syntax für Funktionsdeklarationen mit nachgestelltem Rückgabetyp:
auto fac(int n) -> int { return n <= 1 ? 1 : n*fac(n-1); }
...

vs.

passende Stelle im Standard schrieb:

In a declaration T D where D has the form
D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
ref-qualifieropt exception-specificationopt attribute-specifier-seqopt trailing-return-type
and the type of the contained declarator-id in the declaration T D1 is “derived-declarator-type-list T”,
T shall be the single type-specifier auto. The type of the declarator-id in D is “derived-declarator-type-list
function of (parameter-declaration-clause) cv-qualifier-seq opt ref-qualifier opt returning trailing-return-type”.
The optional attribute-specifier-seq appertains to the function type.

Ich glaube, ich bevorzuge für so etwas doch ein Lehrbuch, anstatt ein technisches Dokument.

daddy_felix

SeppJ schrieb:

]Ich glaube, ich bevorzuge für so etwas doch ein Lehrbuch, anstatt ein technisches Dokument.

Sone

Und jetzt darfst du nachdenken, wie viel du im Lehrbuch gelernt hast und wie viel aus dem Standard. Ich für meinen Teil...

SeppJ

Sone schrieb:

Und jetzt darfst du nachdenken, wie viel du im Lehrbuch gelernt hast und wie viel aus dem Standard. Ich für meinen Teil...

Die Frage ist, was ich wohl lernen wollte.

C++-+-+ schrieb:

Ich hab hier von Galileo "C++11 programmieren" und das ist eigentlich gar nicht schlecht. Ich vermisse aber ein bisschen den Kleinkram. Gibt es ein Buch, dass auch kleine sehr interessante Änderungen/Erweiterungen aufführt? Z.B. neue Funktionen wie std::to_string?

Ich empfehle The C++ Standard Library: A Tutorial and Reference von Josuttis.

http://www.amazon.de/The-Standard-Library-Tutorial-Reference/dp/0321623215/

Behandelt das neue Thema C++11 und ist die absolute STL-Bibel.

SeppJ schrieb:

Nathan schrieb:

Das Buch geht aber wirklich:

+1. Es sind zwar viele kleine Fehler drin, aber die sollte man selbstständig erkennen können, wenn man mit C++ so weit ist, dass man sich für C++11 interessiert.

Hab das Buch heute überflogen. Macht wirklich einen guten Eindruck. Damit ist es aber auch das einzige C++ Buch von Galileo Computing das was taugt, oder?