Sprachmittel, die ihr nie benutzt

volkard

314159265358979 schrieb:

protected -> Weiß er selbst nix dazu.

Er weiß, aber verrät es Dir nicht.

CStoll

private-Vererbung macht mitunter Sinn, um die Fähigkeiten der Basisklasse nutzen zu können ohne dafür eine ist-ein Beziehung darzustellen (das betrifft allerdings nur Grenzfälle, wo virtuelle Methoden oder protected-Methoden der Hilfsklasse eine Rolle spielen). protected-Vererbung ist imho unnötig.

@Sepp: Wenn du schon eine Zahlen-Klasse definierst, sollte die auch alle Operatoren unterstützen, die von int bzw. double bekannt sind - inklusive der unären Vorzeichen-Operatoren.

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?

So oder so verrät das (mir) das aber noch keinen sinnvollen Einsatzzweck. Obwohl, irgendeiner wird sich wohl konstruieren lassen.

Nexus

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.

GotW #06

314159265358979

Zitat: "Private inheritance means something entirely different (see Item 39), and protected inheritance is something whose meaning eludes me to this day."

XSpille

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?

pumuckl

Sprachmittel, die ich nie einsetze:

Exception-Spezifikationen
variable Argumentlisten
Speicherklassen-Schlüsselwörter register und auto
Bitfelder
Digraphen, Trigraphen, alternative Schlüsselwörter ( and etc.)
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 - und delete -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.

314159265358979

Devenv schrieb:

private Vererbung is fuern Arsch.

Das würde ich so pauschal nicht behaupten.

Verwendet ihr irgendwann mal placement new?

krümelkacker

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.

pumuckl

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.

Biolunar

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

otze

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

pumuckl

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.

314159265358979

Kannte sie zwar, aber noch nie gebraucht.