C++11-Buch gesucht

SeppJ schrieb:

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/

SeppJ

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.

Kellerautomat

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.

SeppJ schrieb:

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.

SeppJ

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.

http://xkcd.com/386/

SeppJ schrieb:

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.

Sone

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.

Sehe ich genauso.

kurzer generischer Anwendercode wichtig

Ja, und da gehen unsere Meinungen auseinander.

Nur ist es trotzdem eines der unwichtigsten Features.

Sone

SeppJ schrieb:

Ist das eine offizielle Sortierung nach Wichtigkeit?

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

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.

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...

Nathan

stdexcept schrieb:

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.

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

Nathan

stdexcept schrieb:

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

stdexcept schrieb:

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.

SeppJ schrieb:

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...

SeppJ

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.

SeppJ schrieb:

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?

SeppJ

stdexcept schrieb:

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);

SeppJ schrieb:

stdexcept schrieb:

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);

Schön getrollt. Und was passiert dann mit der Message?

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.