C++11-Buch gesucht

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?

Hi,
du bist leider in eine Falle getappt. Galileo Computing ist bekannt, für die schelchtesten C++ Bücher.
Nun zu den guten Büchern. Du willst also eines, das auch C++11 behandelt. Hmm, da fallen mir aktuell nur 2 ein:
http://www.amazon.de/C-Primer-Stanley-B-Lippman/dp/0321714113/ref=sr_1_1?ie=UTF8&qid=1372422686&sr=8-1&keywords=c%2B%2B+primer
http://www.amazon.de/C-Programming-Language-Bjarne-Stroustrup/dp/0321563840/ref=sr_1_1?s=books-intl-de&ie=UTF8&qid=1372422706&sr=1-1&keywords=c%2B%2B+language

Nathan

out schrieb:

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.

SeppJ

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.

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

Nathan

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.

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

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