pimpl ja/nein

[Jonathan]

Ich bin neulich nochmal über das pimple-Idiom gestoßen, und finde, dass es sich eigentlich ganz gut anhört. Folgender Artikel schien auch einen recht guten Überblick zu verschaffen:
http://herbsutter.com/gotw/_100/

Meine Frage ist jetzt: Benutzt ihr es, ist es in der Praxis den zusätzlichen Aufwand wert, wie viele Probleme macht es und benutzt man es eher überall wo es geht (auch für interne Klassen) oder nur an manchen Stellen (Schnittstelle von einer Bibliothek, z.B.). Eben so ein bisschen Praxiserfahrung.

[RazorX]

Also ich benutze dieses D-Pointer Pattern (alias pimpl) schon ganz gerne, da du so lästige Abhängigkeiten eleminieren kannst. Als Beispiel du schreibst eine GameEngine und der Anwender soll nicht zwangsläufig das DX SDK installieren müssen. Dann musst du alle Member die mit DirectX in Verbindung stehen auslagern eben in diese private Implementierung. Probleme hatte ich damit bis jetzt noch nicht, kann es nur empfehlen. (Vorallem werden die Klassen in IntelliSense schön abgespeckt)

MfG

[Krishty]

Als Beispiel du schreibst eine GameEngine und der Anwender soll nicht zwangsläufig das DX SDK installieren müssen.

Dann muss die Engine aber vorkompiliert ausgeliefert werden. Und wenn das passiert, kannst du dasselble durch eine abstrakte Schnittstelle realisieren.

Ich benutze Pimpl aus Trotz nicht – weil das was ist, was die Sprache machen sollte und nicht der Programmierer. Bloß, weil die Trennung zwischen öffentlicher Deklaration und privater Implementierung in C++ ein riesiger Haufen Dinoscheiße ist, werde ich nicht meine Programmstruktur um eine Indirektion pro Objekt verkomplizieren.

Es gab mal eine Zeit (lange lange her), in der ich die Implementierung getrennt habe, indem die Objektdeklaration nur ein unsigned char-Array von der Größe der tatsächlichen Implementierung gekriegt hat. Das war aber von Hand quasi unwartbar und zu debuggen eine Qual. Pimpl ist da die deutlich einfachere Alternative – zumindest für den Programmierer; nicht für den Compiler.

Ich mache mir übrigens schon lange keine Gedanken mehr darüber, Implementierungen geheimzuhalten. Meine Kompilierzeit liegt dank Bruch mit der C-Laufzeitbibliothek und allen APIs knapp über einer Sekunde; einfach alle abhängigen .cpps und .hpps ins Projekt zu schmeißen ist schneller als erst statische Bibliotheken aufzubauen; davon, meine genialen Algorithmen geheim zu halten, habe ich nichts. Außerdem ist die Hälfte meiner Objekte POD; da gibt es nicht viel zu verstecken.

[kimmi]

Wir benutzen pimpl zur Optimierung der Buildzeiten eben durch die bereits erwähnte Eleminierung von Abhängigkeiten. Das liegt aber daran, dass ein Build hier gern einige Stunden dauert.

Gruß Kimmi

[simbad]

Ich musste erstmal schauen, was das ist und welchen tieferen Sinn das erfüllen soll.
Halte es da wie Krishty. Wenn was nach aussen verdeckt sein soll, wird ne interface klasse definiert und die Abhängigkeiten zu den manchmal ins gigantische wachsenden includes lasse ich eh vom Code-Generator erzeugen und sind mir daher eh wurscht.

Da ich vieles unter Linux erledige, sind mir die Compile-Zeiten auch recht wurscht, da ich dafür meinen 4x4 Server habe. Da kann man getrost 20 Compiler parallel starten. Unter Windows macht man im Zweifel halt ne Kaffee/Tee Pause.

[Andre]

Ich lass das mal einfach hier: http://xkcd.com/303/ :roll:

[kimmi]

Ich musste erstmal schauen, was das ist und welchen tieferen Sinn das erfüllen soll.
Da ich vieles unter Linux erledige, sind mir die Compile-Zeiten auch recht wurscht, da ich dafür meinen 4x4 Server habe. Da kann man getrost 20 Compiler parallel starten.

So etwas haben wir auch, trotz dessen braucht's einige Stunden :).

Gruß Kimmi