http://www.heise.de/developer/artikel/C-11-auch-ein-Stimmungsbild-1345406.html

Viel Spaß beim Lesen,
T.

Dennoch wuerde ich im Beruf C++ nur benutzen, wenn Performance eines der wichtigsten Kriterien ist. In allen anderen Faellen ist .NET und Java mittlerweile einfach zu ueberlegen.

Den neuen Standard finde ich uebrigens eher enttaeuschend. Habe mir viel mehr im Bereich Multithreading erwartet...

~
edit durch SeppJ: Mal wieder den von Pi angezettelten Flamewar aus dem Thread gelöscht. Musste dazu auch Teile deines Beitrags ändern.~

Dennoch wuerde ich im Beruf C++ nur benutzen, wenn Performance eines der wichtigsten Kriterien ist. In allen anderen Faellen ist .NET und Java mittlerweile einfach zu ueberlegen.

Das uebrige BlaBla.

Ich darf auf der Arbeit aber keine Abhängigkeit zu boost einführen, für mich
ist das also schon ein wichtiges Kriterium, den Kram im Standard zu haben.

Auch hoffe ich, dass mittel/langfristig alle die Standard-Klassen nutzen
und nicht Eigenentwicklungen, damit ich nicht QSharedPointer, boost::shared_ptr
und std::shared_ptr gleichzeitig habe.

Wichtiger finde ich allerdings unique_ptr, ganz einfach, weil es dafür in
C++03 keinen adäquaten Ersatz gibt.

Unterm Strich sind smart_ptr sicherlich gut geeignet unter den TOP10 des
neuen Standards. Wer anderer Meinung ist: Welches im Artikel nicht genannte
Feature ist wichtiger und warum?

Das uebrige BlaBla.

http://de.wikipedia.org/wiki/Ironie

/// Alternative implementation for static_assert() C++0x.
template<bool T>
class StaticAssert;
template<>
class StaticAssert<true> {
};
#define STATIC_ASSERT(expression) StaticAssert<(expression)>()

Schön wäre noch, wenn der Compiler den Kopierkonstruktor und den Zuweisungsoperator nicht automatisch generieren würde. Lässt sich aber nach dem Google-Style-Guide (s.u.) oder durch "boost::noncopyable" ganz gut umgehen. Wobei ich ersteren Ansatz vorziehe, um Vererbung zu vermeiden. Ist dann Geschmackssache, ob man Compilerfehler oder Linkerfehler bei Metacode vorzieht.

/// A macro to disallow the copy constructor and operator= functions.
/// This should be used in the private declarations for a class (Google).
#define DISALLOW_COPY_AND_ASSIGN(T) \
  T(const T&);                      \
  void operator=(const T&)

Da ich Boost nicht verwenden darf, ist die Einführung von Multithreading in die Sprachelemente eine angenehme Bereicherung. Nur hoffentlich erwarte ich jetzt nicht zuviel...

Wenn man nach der Verwendungshäufigkeit geht, würd ich sagen, dass unique_ptr sehr viel wichtiger ist als shared_ptr .

OK. Ich hab shared_ptr gesagt und "die neuen Smartpointer" gemeint. Der Autor vielleicht auch, unique_ptr erwähnt er ja gar nicht nochmal gesondert.

Schön wäre noch, wenn der Compiler den Kopierkonstruktor und den Zuweisungsoperator nicht automatisch generieren würde.

class Foo
{
  Foo(Foo const&) = delete;
  Foo& operator=(Foo const&) = delete;
};

// Preloads the given address into L1/L2 cache.
inline void GenericPrefetch(char* address) {
#if defined(ENABLE_PREFETCH)
  _mm_prefetch(address, _MM_HINT_T2);
  _mm_prefetch(address + 64, _MM_HINT_T2);
#else
  UNREFERENCED_FORMAL_PARAMETER(address);
#endif
}

Ich umgehe das mit dem kleinen Makro:

/// Suppress warnings about an unreferenced formal parameter.
#define UNREFERENCED_FORMAL_PARAMETER(x) static_cast<void> (x)

Schön wäre noch, wenn der Compiler den Kopierkonstruktor und den Zuweisungsoperator nicht automatisch generieren würde.

class Foo
{
  Foo(Foo const&) = delete;
  Foo& operator=(Foo const&) = delete;
};

Das habe ich ja noch nie gesehen... Gehört das zu C++0x, oder habe ich etwas verpasst?

Ja, du kannst so explizit Funktionen aktivieren/deaktivieren, indem du = delete/default schreibst.

Coole Sache...

Quelle Wikipedia C++11:
"An attempt to call f() with an int will be rejected by the compiler, instead of performing a silent conversion to double. This can be generalized to disallow calling the function with any type other than double as follows:"

struct OnlyDouble {
    void f(double d);
    template<class T> void f(T) = delete;
};

knivil schrieb:

Das uebrige BlaBla.

http://de.wikipedia.org/wiki/Ironie

Und dein Ironiesignal ist wo?

Schön wäre noch, wenn der Compiler den Kopierkonstruktor und den Zuweisungsoperator nicht automatisch generieren würde. Lässt sich aber nach dem Google-Style-Guide (s.u.) oder durch "boost::noncopyable" ganz gut umgehen. Wobei ich ersteren Ansatz vorziehe, um Vererbung zu vermeiden. Ist dann Geschmackssache, ob man Compilerfehler oder Linkerfehler bei Metacode vorzieht.

Mit boost::noncopyable gibt es auch Compilierfehler, nicht?

Das Generieren von Kopierkonstruktor und (Kopier-)Zuweisungsoperator sind aber in bestimmten Situationen auch "deprecated". Ich kann mir vorstellen, dass das dem ein oder anderen Compiler eine Warnung wert sein dürfte. Dann bekommt man wenigstens eine Warnung, wenn man mal die Dreierregel verletzt hat. Wenn man selbst mindestens eine Move-Operation deklariert, dann wird auch nichts mehr vom Compiler selbst deklariert/definert. Besser geht's eigentlich nicht, ohne Rückwärtskompatibilität zu C++98 zu verlieren.

Was Rvalue-Referenzen angeht, ist der Artikel leider nicht auf dem aktuellen Stand. Und Move-Semantik, Perfect Forwarding, Variadic Templates, auto, decltype find ich jetzt auch wichtiger als shared_ptr.

Mit boost::noncopyable gibt es auch Compilierfehler, nicht?

Stimmt, Zuweisung und Kopieren sind ja privat implementiert....

Noch mal zu dem heise-Artikel: ich muß sagen, das es gut ist, das es wenigstens einen deutschen Artikel gibt. Es wäre schön, wenn da mehr kommen würde.

Sehe ich sehr ähnlich. Habe das Thema auch deshalb hier eingestellt, um eine rege Diskussion anzuregen und daraus noch mehr zu erfahren. Denn ich bin selbst nicht tief in der Materie C++11.

template< class ...char >
class t_parser
{
};

t_parser< "5+3*7" > p;

Da es das ja noch nicht mit c++11 gibt: gibts irgendeinen workaround, wie man einen string trotzdem mit templates auswerten kann?
(ich meine nicht sowas wie t_parser<'5','+','3'>)

Weiß wer eigentlich, wann (und ob) es möglich sein wird, einen string als template parameter zu übergeben?
z.B.

template< class ...char >
class t_parser
{
};

t_parser< "5+3*7" > p;

Da es das ja noch nicht mit c++11 gibt: gibts irgendeinen workaround, wie man einen string trotzdem mit templates auswerten kann?
(ich meine nicht sowas wie t_parser<'5','+','3'>)

Das wird nicht möglich sein. Allerdings gibt es selbstdefinierte Literale, die man für diesen Zweck benutzen kann.

template <char... c> struct expression {};
template <char... c> constexpr expression<c...> operator "" _exp() { return expression<c...>(); }

template <typename T> class t_parser {};

t_parser< decltype("5+3*7"_exp) > p;

Falls dein Compiler constexpr ausreichend unterstützt (also z.B. gcc-4.6+) und deine Strings als benannte Konstanten vorliegen, gibt es auch Möglichkeiten, die Zeichen dieses Strings als Templateparameter zu verwenden, hier habe ich das schon mal gemacht.

Der Threadtitel ist aber sehr suggestiv. Aus welchen Fehlern wurde denn gelernt, von auto_ptr mal abgesehen?

auto_ptr ist eine Sache, aber hauptsächlich export. Steht aber auch im Artikel.

Daraus hat man gelernt, die Concepts erstmal nicht mit rein zu nehmen und die Threading-Geschichte ist noch nicht komplett. Weiterhin werden Libs erstmal in den Technical Reports ausprobiert. Der TR2 ist ja schon angefangen: Boost Filesystem ist drin. Weitere Libs werden folgen, wahrscheinlich Boost Asio.

Allerdings gibt es selbstdefinierte Literale, die man für diesen Zweck benutzen kann.

Bist du dir sicher, dass das auch mit string literals funktioniert (d.h. nicht nur mit integral literals)? Der wikipedia Artikel scheint mir da anderes zu sagen (obwohl ich eigentlich eher geneigt bin dir zu glauben als einem wikipedia Artikel wenns um c++ geht).
http://en.wikipedia.org/wiki/C%2B%2B11#User-defined_literals