3. Gelernt aus Fehlern

Gelernt aus Fehlern

  • B

    Den Artikel les ich mir jetzt auch nicht durch, heise Developer ist allgemein nichts für mich, aber dass shared_ptr für viele das wichtigste Feature von C++11 sein wird, seh ich auch so. Das sind natürlich alles Leute, die pi auch nicht ernst nehmen würde, aber was solls. 🙂

    0

  • Also meiner Meinung nach sind die wichtigsten C++11 Features auto, lambdas, rvalue-refs, variadic templates und initializer lists. Wenn man nach der Verwendungshäufigkeit geht, würd ich sagen, dass unique_ptr sehr viel wichtiger ist als shared_ptr . Einen tatsächlichen Fall von Shared-Ownership hab ich vergleichsweise selten (um nicht zu sagen praktisch nie), nicht nur in C++.

    0
  • ?

    Richtig, es gibt shared_ptr bei boost. Man könnte also argumentieren, dass
    shared_ptr als neues Element des Standards wenig positives bringen.

    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?

    0
  • T

    knivil schrieb:

    Das uebrige BlaBla.

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

    0
  • T

    Mir gefällt die Einführung des static_assert() Ausdrucks, um "besseren" Template-code zu schreiben. Dann kann ich endlich auf solche Konstrukte verzichten:

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

    0
  • B

    dot schrieb:

    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.

    0
  • E

    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;
};
    0
  • T

    Vielleicht geht das jetzt zu weit, aber gibts eine elegantere Lösung in Verbindung mit C++0x hinsichtlich berechtigter Compiler-Warnings?

    // 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)
    0
  • T

    Ethon schrieb:

    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?

    0
  • 3

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

    0
  • T

    final finde ich auch ganz praktisch.

    0
  • T

    314159265358979 schrieb:

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

    👍

    0
  • K

    this->that schrieb:

    knivil schrieb:

    Das uebrige BlaBla.

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

    Und dein Ironiesignal ist wo?

    0
  • K

    Tomahawk schrieb:

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

    0
  • T

    krümelkacker schrieb:

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

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

    0
  • A

    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.

    0
  • T

    Artchi schrieb:

    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.

    0
  • G

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

    0
  • K

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

    0
  • C
    Mod

    GorbGorb schrieb:

    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.

    0
Anmelden zum Antworten