3. Sprachmittel, die ihr nie benutzt

Sprachmittel, die ihr nie benutzt

  • ?

    Nexus schrieb:

    Exception-Spezifikationen sind wenigstens bald deprecated, export wird ganz entfernt.

    Good point. Aber wieso ist im neuen Standard noexcept drin? Tut es nicht genau das selbe?

    0
  • N

    exceptthis schrieb:

    Good point. Aber wieso ist im neuen Standard noexcept drin? Tut es nicht genau das selbe?

    Nein, noexcept ist schon sinnvoll, um Funktionen mit Nothrow-Garantie kennzuzeichnen.

    Es gab hier schon ein paar Threads dazu, da könntest du Genaueres darüber finden. Z.B. ab hier (ist etwas viel Noise, beachte vor allem die Beiträge von krümelkacker und Shade Of Mine).

    0
  • O

    Nexus schrieb:

    SeppJ, du hast noch einiges aufgezählt, das ich auch nie verwende. Z.B. Inline-Assembler, funktionslokale Klassen (deren Schicksal ist mit Lambdas eh besiegelt)

    Sie sind erst mit dem C++0x Standard wirklich einsetzbar. Vorher konnten sie ja keine Templateargumente sein. Und für alles, was nur ein klein wenig komplizierter ist, sind lambdas eh unübersichtlich und funktionslokale Klassen auf einmal weit vorne.

    Ansonstne kann ich mich SeppJs Liste ganz gut anschließen. Mutable kommt bei mir momentan leider ein wenig zu häufig vor und dynamic_cast brauche ich leider auch ab und zu, da ich templates und abstrakte Interfaces unter einen Hut kriegen muss.

    und natürlich für sowas:

    Base* obj=...;
OptimizedDerived* objOpt = dynamic_cast<OptimizedDerived*>(obj);
if(objOpt){
    kernel=createOptimizedKernel(objOpt);
}
else
{
    kernel=createStandardKernel(obj);
}

    wenn mir jemand sagen kann, wie ich sowas ohne dynamic_cast lösen könnte, wäre ich dankbar. Ohne Abstrakte Basisklassen ist das ja trivial.

    0
  • N

    otze schrieb:

    Sie sind erst mit dem C++0x Standard wirklich einsetzbar. Vorher konnten sie ja keine Templateargumente sein. Und für alles, was nur ein klein wenig komplizierter ist, sind lambdas eh unübersichtlich und funktionslokale Klassen auf einmal weit vorne.

    Wirklich? Ich kann mir nicht vorstellen, die jemals gross einzusetzen. Sobald etwas ein wenig komplizierter wird, kommt es bei mir eh aus der Funktion raus in einen detail -Namensraum. Lambdas hingegen kann man schön für triviale Funktoren benutzen.

    otze schrieb:

    wenn mir jemand sagen kann, wie ich sowas ohne dynamic_cast lösen könnte, wäre ich dankbar. Ohne Abstrakte Basisklassen ist das ja trivial.

    Eine virtuelle Funktion in Base und OptimizedDerived geht nicht (z.B. wegen festgelegter Klassen)?

    Base* obj = ...;
kernel = obj->createKernel();
    0
  • C
    Mod

    otze schrieb:

    und natürlich für sowas:

    Base* obj=...;
OptimizedDerived* objOpt = dynamic_cast<OptimizedDerived*>(obj);
if(objOpt){
    kernel=createOptimizedKernel(objOpt);
}
else
{
    kernel=createStandardKernel(obj);
}

    wenn mir jemand sagen kann, wie ich sowas ohne dynamic_cast lösen könnte, wäre ich dankbar. Ohne Abstrakte Basisklassen ist das ja trivial.

    Wäre das nicht einfach durch eine entsprechende virtuelle Funktion zu lösen?

    0
  • ?

    Was Memberzeiger angeht:

    template<typename T, typename D, typename F = std::plus<D> >
class member_accumulation_functor {
public:
  inline explicit member_accumulation_functor(D T::*p, F const &f = F())
    : ptr_(p), func_(f) {}

  inline D operator()(D const &prev, T const &x) {
    return func_(prev, x.*ptr_);
  }

private:
  D T::*ptr_;
  F func_;
};

template<typename T, typename D, typename F>
inline member_accumulation_functor<T, D, F> member_accumulator(D T::*p, F const &f) {
  return member_accumulation_functor<T, D, F>(p, f);
}

template<typename T, typename D>
inline member_accumulation_functor<T, D> member_accumulator(D T::*p) {
  return member_accumulation_functor<T, D>(p);
}

...

struct foo {
  double x, y, z;
} foo_array[10];

double sum = std::accumulate(foo_array, foo_array + 10, member_accumulator(&foo::y));

    Jetzt kann man natürlich argumentieren, dass das sauberer mit get-Methoden x(), y() und z() gelöst wäre, aber mal unter uns Pastorentöchtern, im namespace { } benutzt man der Schnelle halber halt doch mal nackte Structs, und gelegentlich hat man ja auch mit C-APIs oder generell nackten Structs anderer Leute zu tun. Es ist nicht besonders häufig, dass man so etwas braucht, aber gelegentlich doch ganz praktisch zu haben.

    Was ich nicht (mehr) einsetze, weil es meiner Erfahrung nach unnötig Flexibilität entfernt, sind Templates als Template-Argumente, etwa

    template<typename T, template<typename> class U> class foo { U<T> bar; };

foo<int, my_template> baz;

    Das ist meiner Meinung nach besser als

    template<typename T> class foo { T bar; }

foo<my_template<int> > baz;

    geschrieben. Kommt auch selten als Pflichtparameter vor, und die Standardbibliothek hält es beispielsweise mit Vergleichsfunktionen ähnlich.

    0
  • O

    camper schrieb:

    Wäre das nicht einfach durch eine entsprechende virtuelle Funktion zu lösen?

    Kann man machen. Aber das is thalt nur ein einziger mathematischer Sonderfall (der recht wichtig ist). Und da wollen wir eigentlich kein abstraktes Interface mit zu müllen. Es gibt zwar mehr Sonderfälle, aber jede braucht ihre eigene handgedengelte Lösung.

    0
  • N

    @ seldon: Ich verwende Template-Template-Parameter hauptsächlich bei Policy-Based-Design. Und da ich die Problemstellung des Akkumulators in der Form recht selten habe, hätte ich wohl eine guten alte Schleife genommen 😉

    @ otze: Oder du nimmst einen Dispatcher, der irgendeine Typ-/Kategorie-ID auf Funktionen abbildet. Prinzipiell eine std::map<std::type_info, std::function<void(Base*)>, comp> , eventuell auch was Anderes als type_info . Ist besonders praktisch, um virtuelle Funktionen in Klassen zu simulieren, deren Interface man nicht antasten kann/will. Ich hätte auch eine fertige Implementierung dazu.

    typeid hat allerdings zwei Probleme: Vergleiche (und dadurch dispatchte Aufrufe) sind recht langsam. dynamic_cast allerdings auch. Ausserdem erkennst du keine Derived-To-Base-Konvertierungen, eine von OptimizedDerived abgeleitete Klasse müsste also separat beim Dispatcher registriert werden. Von daher könnte sich unter Umständen eine Funktion Base::GetID() bewähren, falls du mehrere Klassen gleich behandeln willst.

    Doch ob sich das in deinem Fall lohnt, kann ich nicht sagen. Virtuelle Funktionen wären wohl das Naheliegendste. Aber ab und zu sind unkonventionelle Lösungen ganz nützlich.

    0
  • W

    SeppJ schrieb:

    Hier auch mal mein Senf, falls es jemandem interessiert:
    Sprachmittel, die ich nie einsetze:

    • Exception-Spezifikationen true
    • variable Argumentlisten Nur in Makros, ansonsten variadic templates 😉
    • Speicherklassen-Schlüsselwörter register und auto (in seiner alten Bedeutung) true
    • Pointer-to-Member (nicht Memberfunktionszeiger) (nur mal versehentlich, als ich einem Compilerfehler begegnet bin) wow, kannte ich gar nicht
    • Function-Style- und C-Casts true, was ist eigentlich der Unterschied zwischen einem Function-Style-Cast und einem Konstruktoraufruf?
    • Bitfelder true
    • Digraphen, Trigraphen true
    • export true
    • eigene new - und delete -Operatoren true, außer zum Debuggen, bevor ich smart-Pointer entdeckt habe
    • dynamic_cast true, außer in altem Code mit schlechtem Design
    • union true
    • goto , Labels true
    • volatile true, außer bei Mikroprozessor- und evtl. Multithread-Programmen (welche ich im Moment nicht schreibe)
    • Inline-Assembler
    • wchar_t , wide Strings & Co. verwende ich durchaus, allerdings nicht mit wchar_t, da wchar_t manchmal nur 2 Byte breit ist und das dann nur halbes Unicode wäre
    • Lokale Klassen (d.h. Klassen in Funktionen, nicht Klassen in Klassen) true
    • operator->* , operator~ sehr spezifisch, ~ z.B. für Bit-Frickling auf dem Mikroprozessor, -> selbst überladen nicht aber für den Aufruf von Memberfunktionen erst gestern verwendet (hast du operator.* vergessen?)*
    • Überladung von: operator->* , operator& , operator~ , operator+ (unär), logische Verknüpfungsoperatoren. true
    • Präprozessordirektiven: #line, #error, Nulldirektive 😃 , im Standard vordefinierte Makros (die sind total nutzlos!)

    #line und Nulldirektive kannte ich gar nicht (Nulldirektive zumindest nicht als solchese Wort, nur als "Designzeichen"); #error für Plattform-Fehler; __FILE__, __LINE__, __DATE__ und __TIME__ evtl. zu Debuggingzwecken
    Sehr selten:

    • virtuelle Vererbung true + protected-/private-Vererbung
    • Funktionstemplate-Spezialisierung momentan nicht
    • const_cast true
    • Arrays true, dazu gibts ja (seit kurzem/bald, je nach Compiler) std::array
    • switch Ja, kaum zu glauben, aber es kommt einfach nie vor, außer bei Hausaufgaben im Forum. true
    • mutable true, kannte ich noch gar nicht
    • explicit Auch kaum zu glauben. Aber meine Konstruktoren haben irgendwie immer entweder 2+-Argumente oder sollen tatsächlich implizit sein. true
    • float, short, signed char, long double true
    • continue selten
    • Überladung von: operator, , operator- (unär) Komma-Operator nicht, unäres Minus schon (was spricht dagegen?)

    Auch sehr selten bis gar nicht: RTTI

    0
  • Mod

    wxSkip schrieb:

    virtuelle Vererbung true + protected-/private-Vererbung

    Oh, die habe ich noch vergessen. Fallen unter nie.

    [*]Überladung von: operator, , operator- (unär) Komma-Operator nicht, unäres Minus schon (was spricht dagegen?)

    Es spricht (im Gegensatz zum Komma) nichts dagegen, unäres Minus zu überladen, ich brauchs nur nie.

    0
  • W

    SeppJ schrieb:

    Es spricht (im Gegensatz zum Komma) nichts dagegen, unäres Minus zu überladen, ich brauchs nur nie.

    Aber operator* und operator/ brauchst du?

    0
  • Mod

    wxSkip schrieb:

    Aber operator* und operator/ brauchst du?

    Benutzen: klar. Überladen: Ja, auch. Iteratorenklassen, mathematische Klassen. Kommt nicht oft vor, aber auch nicht "fast nie". Und solche Klassen aktiv benutzen kommt dauernd vor, das würde ich auch zählen.

    0
  • W

    SeppJ schrieb:

    Iteratorenklassen, mathematische Klassen.

    Bei Iteratorenklassen meinst du wohl den unären?
    Bei mathematischen Klassen kann man zwar a * -1 oder 0 - a schreiben, aber dort könnte man doch trotzdem den unären Minus-Operator überladen, oder?

    0
  • ?

    SeppJ schrieb:

    wxSkip schrieb:

    virtuelle Vererbung true + protected-/private-Vererbung

    Oh, die habe ich noch vergessen. Fallen unter nie.

    Seit boost::noncopyable verwende ich die private Vererbung sehr häufig.

    0
  • Mod

    wxSkip schrieb:

    SeppJ schrieb:

    Iteratorenklassen, mathematische Klassen.

    Bei Iteratorenklassen meinst du wohl den unären?

    Ja.

    Bei mathematischen Klassen kann man zwar a * -1 oder 0 - a schreiben, aber dort könnte man doch trotzdem den unären Minus-Operator überladen, oder?

    Ja, könte man. Ich streite auch gar nicht ab, dass das nützlich sein kann. Ich brauch's bloß irgendwie fast nie. Denk dran, dass ich bei mir unter fast nie auch Mittel wie switch gepackt habe. Vielleicht programmiere ich einfach anders.

    0
  • W

    Kann mir mal jemand erklären, was das für ein Sprachmittel sein soll?
    http://cdecl.ridiculousfish.com/?q=(double+(^)(int+%2C+long+long+))foo
    Das habe ich noch nie gesehen, geschweige denn benutzt.

    0
  • N

    Soweit ich weiss, handelt es sich um eine Spracherweiterung (C++/CLI), wo ^ vom GC verwaltete Zeiger darstellt.

    0
  • 3

    Nicht ganz. Das ist eine eigenen Sprache von Microsoft, auch Managed C++ genannt. Quasi C++ mit .NET.

    0
  • Administrator

    314159265358979 schrieb:

    Nicht ganz. Das ist eine eigenen Sprache von Microsoft, auch Managed C++ genannt. Quasi C++ mit .NET.

    C++/CLI ist der Nachfolger von Managed C++ und ist C++ mit .Net.
    Weder Managed C++ noch C++/CLI sind neue Sprachen, beide bauen auf Erweiterungen auf. Managed C++ hat dabei ausschliesslich Kompilererweiterungen verwendet, also nach dem C++ Standard legale Erweiterungen. Ich bin mir nicht ganz sicher, ob alles legal war, aber deutlich mehr als bei C++/CLI. C++/CLI verwendet dagegen illegale Erweiterungen (z.B. bei den Schlüsselwörtern), dafür muss man nicht überal __ (doppelter Unterstrich) hinschreiben und der Code ist deshalb leserlicher.

    Grüssli

    0
  • 3

    Okay, so genau weiß ich das auch nicht 🤡

    0
Anmelden zum Antworten