du bist leider in eine Falle getappt. Galileo Computing ist bekannt, für die schelchtesten C++ Bücher.

Das Buch geht aber wirklich:
Gleich in den ersten Kapiteln kommen Dinge wie RAII, Exception Safety und Const Correctness dran.

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.

(Wobei ich gerade überrascht bin: Das eigentlich recht wichtige to_string steht tatsächlich nicht drin)

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.

Zum Beispiel? Mir ist nichts derartiges aufgefallen.
(Ich schaue mir aber selten Codebeispiele an, und wenn übernehme ich eh nichts daraus).

Zum Beispiel? Mir ist nichts derartiges aufgefallen.

Ich durchsuche sicherlich nicht das ganze Buch nach einem konkreten Beispiel. Aber ich habe das mal sehr aufmerksam gelesen, es kommen eben dauernd so Kleinigkeiten vor. Zum Beispiel wo wohl an einer Stelle entschieden wurde, die Bezeichner zu ändern und an anderer Stelle im Text wurde die Änderung nicht übernommen.

(Wobei ich gerade überrascht bin: Das eigentlich recht wichtige to_string steht tatsächlich nicht drin)

to_string ist wohl von allen Änderungen in der Standardbibliothek am unwichtigsten. Zuerst kommen Veränderungen an der Sprache selbst.

• Lambda-Ausdrücke ([expr.prim.lambda], §5.1.2)

• rvalue-references, Move-Semantik und die neue Aufteilung in lvalues, xvalues, glvalues, rvalues und prvalues

• decltype und automatic type deduction

• Variadic Templates

• List-initialization ([dcl.init.list], §8.5.4)

• brace-or-equal-initializer für nicht-statische Membervariablen ([class.mem]/5, §9.2 [class.base.init]/8, §12.6.2)

• delegating constructors ([class.base.init]/6, §12.6.2)

• nullptr ([lex.nullptr]/7, §2.14.7)

• user-defined literals ([lex.ext], §2.14.8)

• Diverse neue String-Literal- ([lex.string], §2.14.5) und Zeichen-Typen ([basic.fundamental]/5, §3.9.1):

• raw-strings

• char16_t und char32_t

• Die entsprechenden Präfixe u, U, u8

• Alignment mit alignof , alignas ,... (§20.6.5 & §3.11)

• override und final , noexcept (§15.4 & §5.3.7)

• thread_local storage specifier und der als deprecated markierte register

• constexpr

• ... (!)

Dazu kommt alles aus der Standardbibliothek: Tupel, Regex, Smart-Pointer, Chrono, Threads ( Mutexe), Atomic, alle neuen PRNGs & Distributoren ([rand]), und dann irgendwo, ganz ganz tief, noch unter raw_storage_iterator , liegt to_string .

Ist das eine offizielle Sortierung nach Wichtigkeit? Wichtig ist, was man oft benutzt. to_string zählt da ganz sicher dazu.

Ich hatte noch nie einen guten Anwendungsfall für to_string/stoXXX und wenn, dann waren die nicht anwendbar, weil viel zu ungenerisch (die sollten von/nach Iteratorenpaar gehen, damit ich Substrings nicht erst kopieren muss und ich to_string direkt dorthin leiten könnte, wo ich will).

@TE: Hier ist eine gute C++-Referenz, da hast du eine Übersicht über die Libraryfeatures: http://en.cppreference.com/w/

Ich bastel damit andauernd Strings für Exceptionmeldungen zusammen. Bin ich da so ungewöhnlich? So bekommt man viel leichter Information über die Ausnahmeursache in die Standardexceptions.

Ich bastel damit andauernd Strings für Exceptionmeldungen zusammen.

Strings selber zusammenpfriemeln ... dafür gibt es sprintf, Boost.Format, type-safe printf oder einfach:

template <typename T> using identity = T;

template <typename... Args>
std::string fmt(Args&&... args)
{ std::ostringstream oss;
  identity<bool[]>{oss<<std::forward<Args>(args)...};
  return oss.str();
}

// Je nach Bedarf:
#define errfmt(...) fmt(__FILE__ ":", __LINE__, ": error: ", __VA_ARGS__)

// oder:
struct seppj_exception : std::runtime_error {
  template <typename... A>
  seppj_exception(A&&... args) : runtime_error(fmt(std::forward<A>(args)...)) {}
};
throw seppj_exception("answer", '=', 42);

SeppJ schrieb:

Bin ich da so ungewöhnlich? So bekommt man viel leichter Information über die Ausnahmeursache in die Standardexceptions.

Der Ansatz schlägt fehl, wenn du deine Anwendung mal übersetzen willst. Da ist mindestens das C++11-printf (mit möglicher Indexangabe im Format) Pflicht.

Auf jeden Fall würde ich das nicht direkt mit den std::exceptions machen, sondern ein bisschen mehr Abstraktion aufbauen, dann wird irgendwann auch to_string überflüssig.

http://xkcd.com/386/

Jaja, dicke Templates um stringstreams benutzen, um to_string für unnötig erklären zu können. Ich glaube, du hast voll den Durchblick über den Sinn aller Features.

exceptions => performance egal => kurzer generischer Anwendercode wichtig => stringstream-wrapper

to_string passt nur, wenn performance nicht egal ist oder sich noch niemand die Mühe gemacht hat, die fmt-Funktion zu schreiben.

Ich bastel damit andauernd Strings für Exceptionmeldungen zusammen. Bin ich da so ungewöhnlich? So bekommt man viel leichter Information über die Ausnahmeursache in die Standardexceptions.

Sehe ich genauso.

kurzer generischer Anwendercode wichtig

Ja, und da gehen unsere Meinungen auseinander.

Nur ist es trotzdem eines der unwichtigsten Features.

Ist das eine offizielle Sortierung nach Wichtigkeit?

Nein, das war nur eine Auflistung von Dingen die wichtiger ist als to_string.

Ich bastel damit andauernd Strings für Exceptionmeldungen zusammen. Bin ich da so ungewöhnlich? So bekommt man viel leichter Information über die Ausnahmeursache in die Standardexceptions.

Du bist ungewöhnlich. Oder verhältst dich zumindest entgegen allgemein anerkannter C++-Richtlinen.

http://www.boost.org/community/error_handling.html schrieb:

Format the what() message on demand, if you feel you really must format the message. [...]

Don't worry too much about the what() message. It's nice to have a message that a programmer stands a chance of figuring out, but you're very unlikely to be able to compose a relevant and user-comprehensible error message at the point an exception is thrown. Certainly, internationalization is beyond the scope of the exception class author. Peter Dimov makes an excellent argument that the proper use of a what() string is to serve as a key into a table of error message formatters. Now if only we could get standardized what() strings for exceptions thrown by the standard library...

http://www.boost.org/community/error_handling.html schrieb:

Format the what() message on demand, if you feel you really must format the message. [...]

Don't worry too much about the what() message. It's nice to have a message that a programmer stands a chance of figuring out, but you're very unlikely to be able to compose a relevant and user-comprehensible error message at the point an exception is thrown. Certainly, internationalization is beyond the scope of the exception class author. Peter Dimov makes an excellent argument that the proper use of a what() string is to serve as a key into a table of error message formatters. Now if only we could get standardized what() strings for exceptions thrown by the standard library...

Und wenn man schon mal dabei ist, standardisierte type_info::name.

Und wenn man schon mal dabei ist, standardisierte type_info::name.

Was hat das damit zu tun? Abgesehen davon wird type_info::name maximal für Debuggingzwecke gebraucht.

Mein wichtigster Abschnitt ist hier:

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

Nathan schrieb:

Und wenn man schon mal dabei ist, standardisierte type_info::name.

Was hat das damit zu tun? Abgesehen davon wird type_info::name maximal für Debuggingzwecke gebraucht.

Mein wichtigster Abschnitt ist hier:

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

Ja, klar.
Aber wenn man schon die Exceptions-Messages standadisiert, kann man auch gleich std::type_info::name() standardisieren. Die Funktion hätte eigentlich Potenzial als Type Identifier in Object Factories, aber so...

SeppJ schrieb:

Ich bastel damit andauernd Strings für Exceptionmeldungen zusammen. Bin ich da so ungewöhnlich? So bekommt man viel leichter Information über die Ausnahmeursache in die Standardexceptions.

Du bist ungewöhnlich. Oder verhältst dich zumindest entgegen allgemein anerkannter C++-Richtlinen.

Ich schreibe die Fehlermeldungen nicht für Benutzer. Ich schreibe sie für mich. Für mich ist die Info aus what() sehr aufschlussreich, wenn man sie bloß reinpackt. Was mit to_string trivial einfach ist.

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

Tut mir leid, dann habe ich falsch zitiert.

As a developer, if I have violated a precondition of a library I'm using, I don't want stack unwinding. What I want is a core dump or the equivalent - a way to inspect the state of the program at the exact point where the problem was detected. That usually means assert() or something like it.

Es gibt nichts besseres um Programmierfehler zu finden als assert(). Ich sehe sofort das Problem und kann mir vom Debugger alles anzeigen lassen, was ich will.

Ich weiss noch, wie viel Zeit ich in meinem Java-Projekt reingesteckt habe, schöne Exception-Messages zu generieren (da ging das einfach mit "+", ohne das verbose to_string), nur um am Ende einen Breakpoint auf jedes throw zu setzen...

Ich weiss noch, wie viel Zeit ich in meinem Java-Projekt reingesteckt habe, schöne Exception-Messages zu generieren (da ging das einfach mit "+", ohne das verbose to_string), nur um am Ende einen Breakpoint auf jedes throw zu setzen...

Schließe aus deiner suboptimalen Nutzung von Features nicht auf andere.

stdexcept schrieb:

Ich weiss noch, wie viel Zeit ich in meinem Java-Projekt reingesteckt habe, schöne Exception-Messages zu generieren (da ging das einfach mit "+", ohne das verbose to_string), nur um am Ende einen Breakpoint auf jedes throw zu setzen...

Schließe aus deiner suboptimalen Nutzung von Features nicht auf andere.

Wäre es zu viel verlangt, ein sinvolles Beispiel von Exceptions mit ausführlicher Fehlermeldung zu bringen?

Wäre es zu viel verlangt, ein sinvolles Beispiel von Exceptions mit ausführlicher Fehlermeldung zu bringen?

throw std::thread_exception("Troll found. Name: " + username);