Edit:
ging vergessen: range based for-loop

&& (aber nicht als Ref-Qualifier)
auto
decltype
-> (late-specified return type)
static_assert
std::enable_if und was sonst noch so in <type_traits> drin ist
std::unique_ptr
std::shared_ptr
std::tuple
std::unordered_map
Lambdas

Aber das kann ich mir auch erlauben, weil wir ein sehr kleines Team in einer Forschungseinrichtung sind, dessen Software hauptsächlich "in-house" genutzt wird. Die Hauptsache ist, dass man das für Windows und Linux kompiliert bekommt.

Manchmal auch decltype und auto.
Edit: Und std::initializer_list (sehr praktisch)

• nullptr , static_assert
  - alles aus allen Bibliotheksheadern, falls benötigt.
  - variadic templates, perfect forwarding mit URefs
  - Move-Semantik natürlich
  - Und das öfteste: auto als type-specifier, auch evt. decltype(auto) .
  - Selbstverständlich range-based for, das ist eine Augenweide.
  - Noch viel weiteres.

Und was benutzt ihr aus C++1y?

Und std::initializer_list (sehr praktisch)

Wofür denn das?

Singender Holzkübel schrieb:

Und std::initializer_list (sehr praktisch)

Wofür denn das?

ich vermute, damit er seine eigenen klassen wie aggregate initialisieren kann.

Singender Holzkübel schrieb:

Und std::initializer_list (sehr praktisch)

Wofür denn das?

Diverse Initialisierungen.

Arcoth schrieb:

Und was benutzt ihr aus C++1y?

constexpr

Und was benutzt ihr aus C++1y?

Nichts.

Aber ich freue mich schon ein bisschen auf polymorphe Lambdas und Return-Type Deduction für "normale" Funktionen. Letzteres ist ja besonders für Template-lastigen Code interessant. Damit könnte ich mir hier z.B. die nervigen "->decltype(...)" sparen.

Arcoth schrieb:

Und was benutzt ihr aus C++1y?

constexpr

das gibt es schon in c++11.

Singender Holzkübel schrieb:

Arcoth schrieb:

Und was benutzt ihr aus C++1y?

constexpr

das gibt es schon in c++11.

Ja, aber nicht so!

Sprache: Lambda-Ausdrücke, auto , Range-Based For, Move-Semantik, nullptr

Bibliothek: function , unique_ptr

Was ich nicht oder äusserst selten verwende:
initializer_list, shared_ptr, foreach (wozu?), Encoding-Facetten.

Was ich aus C++14 vermisse:
Return-Type-Deduction, polymorphe Lambdas und Concepts.

Was ich nicht oder äusserst selten verwende:
... foreach (wozu?)

Gibt's in C++ ja auch nicht

Concepts

Achja. Das gibt's ja auch noch (irgendwann vielleicht mal).

/me ist froh, dass "concepts" aus dem C++0x draft rausgeflogen ist und freut sich auf ein entschlacktes "concepts lite".

`auto

nullptr,

std::function

std::unique_ptr

std::shared_ptr

`

ich habe eine Frage bezüglich std::enable_if<Bool,T>

Also wenn der Bool wahr ist, dann hat die Funktion ein Rückgabewert?

also als beispiel:

#ifndef _BEISPIEL_HPP
#define _BEISPIEL_HPP

#ifdef _NO_EXCEPTIONS
#define _EXAMPLE_ true
#else
#define _EXAMPLE_ false
#endif

...
std::enable_if<_EXAMPLE_,DWORD>::type foo(parameters x)
{
   //DO something
  if(/*ERROR*/)
      #ifdef _NO_EXCEPTIONS_
          return 3;
      #else
         throw "You made an ERROR";
      #endif

return 0; // wird Ende der Funktion trotzdem ein return gemacht?
}
...

#endif

Aber ich freue mich schon ein bisschen auf polymorphe Lambdas und Return-Type Deduction für "normale" Funktionen. Letzteres ist ja besonders für Template-lastigen Code interessant.

Benutze ich beides laengst, den ich habe den neusten GCC- und Clang-Snapshot. Ich habe schon die Angewohnheit, gar keine Rueckgabetypen mehr hinzuschreiben, ausser, ich moechte noch implizit konvertieren. Ist ausserst angenehm, weil so die Redundanz aus dem Typsystem entfernt wird.

Also wenn der Bool wahr ist, dann hat die Funktion ein Rückgabewert?

Nein. Falls, und nur falls der bool den Wert true hat, dann hat die Spezialisierung einen Member mit Namen type - das ist ein Typedef auf das zweite Template-Argument. enable_if nutzt man fuer SFINAE, u.a. auch um Funktionen unter bestimten Bedingungen aus dem Overload-Set zu schmeissen. Wenn der bool den Wert false hat, dann ist der Ausdruck std::enable_if<....>::type fehlerhaft. Das ist der Trick. Seit C++11 kann man so etwas fuer Ausdruecke teilweise auch ohne enable_if , mit trailing-return-types und decltype .

Kurz: Macht nur mit Templates Sinn.

Falls du nur einen Compile-time Pruefung auf etwas machen willst, nimm

static_assert( /*eine Bedingung */ false, "Fehlermeldung" );

Ich habe schon die Angewohnheit, gar keine Rueckgabetypen mehr hinzuschreiben, ausser, ich moechte noch implizit konvertieren. Ist ausserst angenehm, weil so die Redundanz aus dem Typsystem entfernt wird.

Hier sehe ich aber ein ähnliches Problem wie bei auto , wenn mit Typinferenz übertrieben wird: Code wird schlechter lesbar. Bei sehr generischem oder templatelastigem Code und in lokal begrenztem Kontext sind solche Features äusserst nützlich, aber für normale Anwendung nicht unbedingt.

Gerade bei Funktionen ist ja die Signatur das API; wenn ich nun die Implementierung anschauen muss, um den Rückgabetyp zu kennen, läuft etwas falsch...

Arcoth schrieb:

Ich habe schon die Angewohnheit, gar keine Rueckgabetypen mehr hinzuschreiben, ausser, ich moechte noch implizit konvertieren. Ist ausserst angenehm, weil so die Redundanz aus dem Typsystem entfernt wird.

Hier sehe ich aber ein ähnliches Problem wie bei auto , wenn mit Typinferenz übertrieben wird: Code wird schlechter lesbar. Bei sehr generischem oder templatelastigem Code und in lokal begrenztem Kontext sind solche Features äusserst nützlich, aber für normale Anwendung nicht unbedingt.

Vorallem explodieren dann die Compiler-Fehlermeldungen, wenn was nicht stimmt.