Gelernt aus Fehlern



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


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


  • 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?



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



  • final finde ich auch ganz praktisch.



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

    👍



  • this->that schrieb:

    knivil schrieb:

    Das uebrige BlaBla.

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

    Und dein Ironiesignal ist wo?



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



  • krümelkacker schrieb:

    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.



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



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



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


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



  • knivil schrieb:

    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.



  • camper schrieb:

    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


  • Mod

    GorbGorb schrieb:

    camper schrieb:

    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

    Da hast du recht. Dann ist das doch nicht so möglich.



  • knivil schrieb:

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

    Vielleicht mal den Artikel lesen, bevor du rumlaberst?



  • camper, hattest du da nicht ien constexpr char[] bei deinem Brainfukc Compiler, dass du irgendwie in dein Template bekommen hast?



  • Doch, hat er ja auch verlinkt. Ich hab zu dem Thema noch nen netten blog Eintrag gefunden:
    http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-part-i/
    Wird Zeit dass ich mir mal nen neuen gcc runterlad...


Anmelden zum Antworten