pImpl Idom noch zeitgemäß?

gallagher

Hallo,

ich habe gerade das Konzept das pImpl Idom nachvollzogen
und da drängte mir folgende Frage in den Kopf:

Ist ein solches Idom noch angebracht, da Compilier-Arbeiten
heutzutage wenig Zeit beanspruchen?

Viele Grüße,
gallagher

pumuckl

gallagher schrieb:

Ist ein solches Idom noch angebracht, da Compilier-Arbeiten
heutzutage wenig Zeit beanspruchen?

Beim pimpl gehts nicht nur um die Compilezeit, sondern auch darum, nicht den Header der gepimplten Klasse mit den diversen benötigten Headern zu verseuchen sondern das in die .cpp zu verlagern. Davon abgesehen sind ~~Compiler~~ Computer, auf denen compiliert wird, zwar heute schneller als zum Zeitpunkt xy, aber das gilt in gewissem Maß sicher auch für die zusätzliche Zugriffszeit über die pimpl-Indirektion.

Zusammengefasst: Pimpl ist noch genauso zeitgemäß wie früher, man muss aber genauso wie früher die Vor- und Nachteile abschätzen/messen und nicht einfach blind drauflospimpln.

Ein Artikel zum pimpl in C++0x:

asc

Da irgendwie pumuckl die Artikellinks vergessen hat, liefere ich mal zwei gotw-Artikel nach, die ich als sinnvoll erachte:
- GotW #100: Compilation Firewalls (Difficulty: 6/10)
- [url=http://herbsutter.com/gotw/_101/]GotW #101: Compilation Firewalls, Part 2 (Difficulty: 8/10)
[/url]

Artchi

Ich finde aber, das das Pimpl Idiom dem Template-Gedanken (der von vielen beschworen wird) im Widerspruch steht.
Oder gibt es da eine "Lösung"?

cooky451

Leider wiederspricht schon das Header/.cpp Konzept dem Templategedanken. Da wird man sich wohl entscheiden müssen.
(Also das Komitee, und solange die da nichts machen, ist alles erlaubt. :xmas1: )

pumuckl

asc schrieb:

Da irgendwie pumuckl die Artikellinks vergessen hat, liefere ich mal zwei gotw-Artikel nach, die ich als sinnvoll erachte:
- GotW #100: Compilation Firewalls (Difficulty: 6/10)
- [url=http://herbsutter.com/gotw/_101/]GotW #101: Compilation Firewalls, Part 2 (Difficulty: 8/10)
[/url]

Danke dir, die meinte ich

pumuckl

Artchi schrieb:

Ich finde aber, das das Pimpl Idiom dem Template-Gedanken (der von vielen beschworen wird) im Widerspruch steht.
Oder gibt es da eine "Lösung"?

Ich finde im Gegenteil, dass das pimpln bzw. grundsätzlich die Header/source-Trennung und templates zwei orthogonale Konzepte sind. Für die Implementierung eines Template sollte man nicht viele Dinge brauchen müssen, die "weggepimplt" werden müssten. Pimpl-Implementierungen können ohne Scham nach Belieben Templates benutzen.

hustbaer

gallagher schrieb:

Ist ein solches Idom noch angebracht, da Compilier-Arbeiten
heutzutage wenig Zeit beanspruchen?

Der war gut, muahaha.
Also mir dauert das lange genug.
Wenn ein rebuild-all des Projekts gleich mal 1,5 bis 2 Stunden dauert...
Und das ist noch nicht wirklich viel, ich kenne Leute die an Projekten arbeiten wo es sich gerade noch ausgeht dass der Nightly Build in 8 Stunden fertig wird.

Artchi

Bei eigenen "in Entwicklung" befindlichen Projekten macht das Pimpl durchaus Sinn. Aber wenn ich eine stabile Bibliothek nutze, die sich alle Jubeljahre ändert, dann reicht es, wenn ich das PCH-Feature meines Compilers nutze, ohne das die genannte Bibliothek das Pimpl nutzt.

ScyllaIllciz

Sollte man nicht auch noch erwähnen, dass man dadurch Binärkompatibilät erreichen kann, siehe Qt Lib's?!

pumuckl

Artchi schrieb:

Aber wenn ich eine stabile Bibliothek nutze, die sich alle Jubeljahre ändert, dann reicht es, wenn ich das PCH-Feature meines Compilers nutze, ohne das die genannte Bibliothek das Pimpl nutzt.

Nö. Wenn ich vermeiden will, zig völlig uninteressante Header mit Implementationsdetails an Klienten auszuliefern, dann pimpl ich den Inhalt der Klassen, die das Interface meiner Bilbiothek darstellen, möglichst weg.

volkard

gallagher schrieb:

ich habe gerade das Konzept das pImpl Idom nachvollzogen
und da drängte mir folgende Frage in den Kopf:

Ist ein solches Idom noch angebracht, da Compilier-Arbeiten
heutzutage wenig Zeit beanspruchen?

Da hat sich über die Zeit nichts geändert. Es war schon immer fast überall unnötig und störend. Und es ist es gleichermaßen noch.
Allerdings gibt es in der Gemeinde derzeit ein paar Missionare, die einem einreden wollen, man müsse fast jede Klasse pimpeln. Jo, klar, daraus kann ein Kult entstehen, die rituelle Betätigung ist nervend und unsinnig genug.

Ethon

Ist auch super um Plattform-Details wie die berüchtigte windows.h etc zu verstecken.

314159265358979

Ich verwende pimpl eigentlich nie. Einen Zeiger auf eine Resource kann ich in einen void* verstecken, was bei den meisten Resourcen wunderbar funktioniert. In den wenigen Ausnahmefällen kann man dann pimpl nehmen, wenns nicht vermeidbar ist.

volkard

314159265358979 schrieb:

Ich verwende pimpl eigentlich nie. Einen Zeiger auf eine Resource kann ich in einen void* verstecken, was bei den meisten Resourcen wunderbar funktioniert. In den wenigen Ausnahmefällen kann man dann pimpl nehmen, wenns nicht vermeidbar ist.

Wenn der Typ nur blöd zum inkludieren ist, kannste auch mit passendem Alignment und Size rohen Speicher reservieren. Alignment und Size kannste im Header behaupten und in der *.cpp mit static_assert garantieren. Dann haste keine Laufzeitverluste und keine Compilezeitverluste. Stört aber beim Debuggen. Kannst mit #ifdef im Debug-Code pimpeln und im Releasecode drauf verzichten. Wobei das so trivial ist, daß man es echt nicht dem Menschen zumuten muß, sich darum zu kümmern. Gibt's bei Eclipse nicht seit zwei Jahren im Refactoring-Menu einen Eintrag, wo man eine Klasse zu pimpl und zurück machen kann?

gallagher schrieb:

...da Compilier-Arbeiten heutzutage wenig Zeit beanspruchen?

Du arbeitest wohl nicht an großen Projekten.

leftshift

volkard schrieb:

Da hat sich über die Zeit nichts geändert. Es war schon immer fast überall unnötig und störend. Und es ist es gleichermaßen noch.
Allerdings gibt es in der Gemeinde derzeit ein paar Missionare, die einem einreden wollen, man müsse fast jede Klasse pimpeln. Jo, klar, daraus kann ein Kult entstehen, die rituelle Betätigung ist nervend und unsinnig genug.

Es gibt in der Gemeinde ein paar Missionare die einem einreden wollen das dieses Idiom unnötig und störend ist. Es hat seinen Platz z.B. bei Portierungen für unterschiedliche Platformen. Wenn ich anfange mit Rohspeicher und Alignment zu fummeln kann ich auch beim Duo Infernale - 'C/Assembler' bleiben (*). Es ist wie bei jedem Pattern ... der einzelne Anwendungsfall entscheidet. Pauschal kann man da garnichts sagen. Die Debatten Pattern ja/nein sind sind schon tausendfach geführt worden, ist das gleiche wie 'welche Programmiersprache ist die beste'.

(*) Rohspeicher und Aligment haben sich bei sehr hardwarenahen Projekten (Treiber) bewährt wo wirklich jeder Zyklus bzw. jedes Byte zählt.

pumuckl

Zum Rohspeicher-Hack hat der GotW auch was geschrieben:

http://www.gotw.ca/gotw/028.htm

Natürlich ist es Quatsch, alles wegzupimpln, was einem über den Weg läuft. Wie bei allen Patterns gibts für jeden Fall, in dem ein Pimpl ein möglicher Lösungskandidat ist, auch weitere Kandidaten, und man muss die Vor- und Nachteile aller Kandidaten gegeneinander abwägen. Und zwar nicht pauschal sondern für jeden Fall einzeln. Allgemeine Aussagen wie "pimpl ist immer Schwachsinn" oder "Alles pimpln was geht" sind Humbug.

volkard

pumuckl schrieb:

Zum Rohspeicher-Hack hat der GotW auch was geschrieben:
http://www.gotw.ca/gotw/028.htm

Damals gab es noch kein C++11: bei 1. hat er also inzwischen unrecht. http://en.cppreference.com/w/cpp/types/aligned_storage
Die anderen Gründe sind schwach; man muß den ~~Rohspeicherhack~~InPlace-Pimpl ja nicht gerade ganz so roh aufführen.

Artchi

pimpl ist kein Pattern, nur mal so nebenbei ins Gedächtnis gerufen. Es ist ein Idiom. Ein Pattern ist Sprach-/Technikunabhängig. Das Idiom ist speziell für eine Sprache/Technik.