Sprachmittel, die ihr nie benutzt
-
314159265358979 schrieb:
Okay, so genau weiß ich das auch nicht

Naja, Hauptsache du hast was dazu gesagt.
Könner schrieb:
So oder so verrät das (mir) das aber noch keinen sinnvollen Einsatzzweck. Obwohl, irgendeiner wird sich wohl konstruieren lassen.
-
Zitat: "Private inheritance means something entirely different (see Item 39), and protected inheritance is something whose meaning eludes me to this day."
-
volkard schrieb:
314159265358979 schrieb:
protected -> Weiß er selbst nix dazu.
Er weiß, aber verrät es Dir nicht.
Weißt du denn, was er weiß und verrätst es uns stellvertretend?

-
Sprachmittel, die ich nie einsetze:
- Exception-Spezifikationen
- variable Argumentlisten
- Speicherklassen-Schlüsselwörter
registerundauto - Bitfelder
- Digraphen, Trigraphen, alternative Schlüsselwörter (
andetc.) export
[]Funktionstemplate-Spezialisierung
[]union
[]goto
[]volatile
[]std::vector<bool>
[]Inline-asm
[*]RTTI
Sehr selten:- virtuelle Vererbung
- Pointer-to-Member (nicht Memberfunktionszeiger)
- Function-Style- und C-Casts
protected-Vererbung- eigene
new- unddelete-Operatoren const_cast,dynamic_cast- Arrays
inline- lokale Klassen (seit C++0x-Lambdas sehr selten)
- Überladung der Operatoren &&,||,,(Komma),binärer Operatoren,op-(unär) -> SEHR selten
- Überladung operator+, -, !=, ... (nur indirekt über boost::operators)
-
private Vererbung is fuern Arsch. Aggregation/Komposition ist in 99,999999999% der Faelle besser.
Und protected Vererbung is einfach nur zu 100% ueberfluessig.
-
Devenv schrieb:
private Vererbung is fuern Arsch.
Das würde ich so pauschal nicht behaupten.
-
Verwendet ihr irgendwann mal placement new?
-
x8vv9 schrieb:
Verwendet ihr irgendwann mal placement new?
Indirekt, wenn ich std::vector benutze.

-
Nie: protected für Membervariablen.
Hab die immer private und für Vererbung nutze ich dann (falls erforderlich) sinnvolle Zugriffsmethoden.
-
Könner schrieb:
314159265358979 schrieb:
private -> "is implemented in terms of".
In der C++ FAQ lite steht's als Quasi-Komposition. Das mit "is implemented in terms of" hab ich auch schon mal gelesen. Widersprechen sich diese beiden nicht?
Nein, ist das gleiche. "Implemented in Terms of" heißt ja nicht viel anderes als "Benutzt die Funktionalität von...", und das ist eine der möglichen Gründe für Komposition.
Pirvate zu erben statt ein Objekt als Komponente aufzunehmen macht nur in wenigen Fällen Sinn, nämlich wenn man etwas braucht/benutzen muss, was die Vererbung einem liefert:
- protected Member
- dynamic_casts oder anderes Gedöns mit Basisklassenpointern innerhalb der erbenden Klasse oder friends davon.
-
Wie sieht es mit function level try Blöcken aus? Hat die schon mal jemand verwendet? Würde mich nicht wundern, wenn viele nicht mal wissen was das ist

-
Biolunar schrieb:
Wie sieht es mit function level try Blöcken aus? Hat die schon mal jemand verwendet? Würde mich nicht wundern, wenn viele nicht mal wissen was das ist

Okay, musste ich nachlesen.
Klingt eigentlich ganz cool?!? Auf jeden Fall übersichtlicher, als try/catch Blöcke direkt in die Funktionen einzufügen.
Wahrscheinlich aber nicht wirklich anwendbar, weil 99% der Programmierer diese Syntax nicht kennen...
-
Biolunar schrieb:
Wie sieht es mit function level try Blöcken aus? Hat die schon mal jemand verwendet? Würde mich nicht wundern, wenn viele nicht mal wissen was das ist

Selten, in Konstruktoren, um dort auftretende Exceptions zu übersetzen.
-
Kannte sie zwar, aber noch nie gebraucht.