Wohin mit Membern
-
Also bei Boost ist mir hauptsächlich aufgefallen, dass es kaum Sachen gibt, die in den zig verschiedenen Libs so richtig konsequent überall gleich gemacht würden.
Ist aber auf jeden Fall der "Stil" den ich in "Fremdcode" am häufigsten gesehen habe.
-
Ich Atme B.
Member haben für mich beim Codeverständnis die größte Bedeutung und bei allen leuten die A schreiben fluche ich, dass ich immer so lange scrollen muss, um irgendwas zu finden...
-
Mir ist eigentlich vollkommen egal ob a oder b, wobei ich eher zu a tendiere. Mir ist die Schnittstelle in der Regel wesentlich wichtiger.
Ich ziehe ohnehin kurze Klassen den langen vor, so das ich die Scrollorgien die otze anspricht, auch nicht so schwer wiegen wenn man den wirklich die Implementierungsdetails benötigt (zudem sehe ich es nicht so, das Member für das Codeverständnis wichtiger sind als die Schnittstelle).
-
wer B bevorzugt ist definitiv ein schlechter Programmierer
-
DrGreenthumb schrieb:
[...] Schlimm genug dass das überhaupt mit in den Header muss.
Gut, in irgendeinen Header muss es, aber was ist mit pImpl?
-
Private Member ganz oben.
Wenn ich mir eine Implementierung anschaue, interessiere ich mich mehr für die Details als für die Schnittstelle. Die sollte abstrahiert in einer Basisklasse oder einem Interface vorliegen.
-
µ schrieb:
..die Schnittstelle. Die sollte abstrahiert in einer Basisklasse oder einem Interface vorliegen.
Es geht hier um C++
-
hustbaer schrieb:
µ schrieb:
..die Schnittstelle. Die sollte abstrahiert in einer Basisklasse oder einem Interface vorliegen.
Es geht hier um C++
Dann ersetze "Interface" durch "Abstrake Basisklasse"
-
Abstrakte Basisklassen meidet man in C++: machen alles langsam wegen virtual
-
µ schrieb:
hustbaer schrieb:
µ schrieb:
..die Schnittstelle. Die sollte abstrahiert in einer Basisklasse oder einem Interface vorliegen.
Es geht hier um C++
Dann ersetze "Interface" durch "Abstrake Basisklasse"
Ich weiss schon was du meinst, nur ist das eben nicht der "C++ way of doing it".
Abstrake Basisklasse = virtual call = langsam.
Direktes Interface = gute Chance für Inlining = potentiell (und meistens auch real) viel schneller.
-
Was ist ein "Interface" in C++?
-
gastfrage schrieb:
Was ist ein "Interface" in C++?
das selbe wie in anderen Sprachen. In dem Fall die (öfffentliche) Schnittstelle der Klasse.
Private-Kram hat da eigentlich gar nichts zu suchen. In C++ muss es wegen dem Speichermodel leider dabei stehen.
Ist mir unbegreiflich wieso man erst die privaten Member sehen will wenn man in einen Header guckt. Die Implementation ist doch eh in einer anderen Datei.
-
DrGreenthumb schrieb:
gastfrage schrieb:
Was ist ein "Interface" in C++?
das selbe wie in anderen Sprachen. In dem Fall die (öfffentliche) Schnittstelle der Klasse.
Ich glaube das war hier damit nicht gemeint, da is im Gegensatz zu abstrakten Basisklassen stand (also in etwa so wie ein Interface in Java).
Würde nun gern wissen wie ich sowas - oder allgemein eine vernünftige Vererbungshierarchie - in C++ realisieren soll, wenn ich keine "bösen langsamen" virtuellen Methoden benutzen darf
-
gastantwort schrieb:
DrGreenthumb schrieb:
gastfrage schrieb:
Was ist ein "Interface" in C++?
das selbe wie in anderen Sprachen. In dem Fall die (öfffentliche) Schnittstelle der Klasse.
Ich glaube das war hier damit nicht gemeint, da is im Gegensatz zu abstrakten Basisklassen stand (also in etwa so wie ein Interface in Java).
Würde nun gern wissen wie ich sowas - oder allgemein eine vernünftige Vererbungshierarchie - in C++ realisieren soll, wenn ich keine "bösen langsamen" virtuellen Methoden benutzen darfMit einem Haufen Templatekram
-
gastantwort schrieb:
DrGreenthumb schrieb:
gastfrage schrieb:
Was ist ein "Interface" in C++?
das selbe wie in anderen Sprachen. In dem Fall die (öfffentliche) Schnittstelle der Klasse.
Ich glaube das war hier damit nicht gemeint, da is im Gegensatz zu abstrakten Basisklassen stand
Doch, genau das war gemeint.
-
abstract polymorphe basisklasse halbherzig zusammengeschustert durch weltfremden langzeitfrickler
