C++11-Buch gesucht

SeppJ

Nathan schrieb:

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.

Nathan

Ach so, sowas meinst du.
Ich dachte so Wurstbrot-Supermarkt-Geschichten.

Sone

SeppJ schrieb:

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

SeppJ

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

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?