3. pImpl Idom noch zeitgemäß?

pImpl Idom noch zeitgemäß?

  • P

    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.

    0
  • V

    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.

    0
  • E

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

    0
  • 3

    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.

    0
  • V

    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?

    0
  • ?

    gallagher schrieb:

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

    Du arbeitest wohl nicht an großen Projekten.

    0
  • L

    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.

    0
  • P

    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.

    0
  • V

    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 RohspeicherhackInPlace-Pimpl ja nicht gerade ganz so roh aufführen.

    0
  • A

    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.

    0

  • volkard schrieb:

    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 RohspeicherhackInPlace-Pimpl ja nicht gerade ganz so roh aufführen.

    Genau.
    Alignment ist kein Thema mehr.
    Das suboptimale Runtime-Assert (sizeof etc.) kann man mittlerweile durch ein static_assert ersetzen.
    Das "passt mal auf auf operator =" ist grundsätzlich richtig, trifft aber genau so auf normales PIMPeLn zu.

    Und... wenn ich wo "custom allocator" lese... pfuh.
    Naja, gibt manchmal Fälle wo es wirklich Sinn macht/OK ist.
    z.B. wenn ich davon ausgehen muss dass mein normaler Allocator thread-safe und auf "wenig Speicherverbrauch" optimiert ist. Wenn ich dann nen Custom-Allocator schreibe der nicht Thread-Safe ist, und nicht auf "wenig Speicherverbraucht" optimiert ist, dann kann das schon was bringen.
    Im speziellen also ja, kann Sinn machen.
    Im Allgemeinen halte ich Special-Case Allokatoren aber für ... Unfug.

    0
Anmelden zum Antworten