PIMPL und Typedef in der versteckten Klasse

Skym0sh0

Das der Destruktor in die CPP muss sowie die Regel der Großen Drei eingehalten werden muss, weiss ich, das habe ich auch gemacht. Das soll jetzt auch nicht Thema sein hier, denn es vergrößert das Beispiel nur immens und bringt keinen semantischen Mehrwert...

daddy_felix

knivil schrieb:

Kompilierzeit verringern

Das ist heute kein Problem.

oh doch, wenn die Projekte groß genug werden...

ein kompletter Clean Build unserer Solution dauert fast eine halbe Stunde... das übernimmt zum Glück der nächtliche Buildserver. Aber bei Änderungen an zentralen Komponenten kann es schonmal 5-10 Minuten dauern, bis das Ding startet.

knivil

Ich habe nicht gesagt, dass es nicht dauert. Ich habe nur gesagt, dass das Problem nicht besteht, weil es anders geloest wird. Auch wird wohl kaum jemand nach dem Trial & Error Prinzip zentrale Komponenten aendern.

volkard

Skym0sh0 schrieb:

Hauptsächlich weil ich meine Compilezeit runterdrehen will und das äussere Interface klein bleiben soll.

Hab ich mir gleich gedacht, nachdem ich Deine Deutsch verstanden hatte. Wir kommen der Sache näher.
Wenn es um komplexte Typem wie angegeben handelt, dann geht das nicht, vermute ich. Wenn es nur darum geht, die <windows.h> loszuwerden, dann geht das sogar ohgne pimpl viel besser.
Wobei Rückgabetypen auch bloß geforwarded sein können. Verträgt sich aber weniger mit Templates.
Ich benutze fast nie pimpl, insbesondere nicht, um compilezeit zu sparen.

Ach, ich verwende es nicht, um was zu verstecken, sondern (extrem selten) um Laufzeitpolymorphie zu haben, ohne Zeiger oder Referenzen zu sehen. Das Verstecken-Können ist dann nur zufällig ein netter Bonus.

Nathan

volkard schrieb:

Ich benutze fast nue pimpl, insbesondere nicht, um compilezeit zu sparen.

Nie oder nur?

volkard

Nathan schrieb:

volkard schrieb:

Ich benutze fast nue pimpl, insbesondere nicht, um compilezeit zu sparen.

Nie oder nur?

nie

cooky451

volkard schrieb:

Wenn es nur darum geht, die <windows.h> loszuwerden, dann geht das sogar ohgne pimpl viel besser.

Wie?

volkard

cooky451 schrieb:

volkard schrieb:

Wenn es nur darum geht, die <windows.h> loszuwerden, dann geht das sogar ohgne pimpl viel besser.

Wie?

<winforward.h>

typedef void* HANDLE;
...

<winforward.cpp>

#include <windows.h>
#include <winforward.h>

static_assert<same_type<void*,HANDLE>>;
...

cooky451

Ja.. und wie rufst du jetzt CreateWindow etc. auf? Ist ja dann auch so eine Art pimpl, nur halt ohne new. Und wenn man noch mehr will, dann muss man das auch alles im Header typedeffen. Und dann ist es auch nicht als plattformunabhängige Kapselung geeignet, weil die typedefs entsprechend angepasst werden müssten. Ne, da bleibe ich lieber bei pimpl.

volkard

cooky451 schrieb:

Ja.. und wie rufst du jetzt CreateWindow etc. auf?´

Wer so fette Brocken aufruft, darf im Allgemeinen sogar die <windows.h> höchstselbst inkludieren.
Mir geht es darum, daß die tausend Helfer-Klassen File, Event, Semaphore, FileMapping, sowie einige Helfer-Funktionen wie sleep oder set dadurch plattformunabhängig werden. daß ich

typedef void* os::FileHandle;

mache, bzw unter linux int statt void*, und ich FileHandle benutze. Dadurch brauche ich kein pimpl, was da wirklich übertrieben langsam wäre.

cooky451 schrieb:

Ist ja dann auch so eine Art pimpl, nur halt ohne new. Und wenn man noch mehr will, dann muss man das auch alles im Header typedeffen. Und dann ist es auch nicht als plattformunabhängige Kapselung geeignet, weil die typedefs entsprechend angepasst werden müssten. Ne, da bleibe ich lieber bei pimpl.

Es ist absolut geeignet für Plattformabhängigkeit wegmachen und gleichzeitig Compilezeit zu sparen, wenn man nicht auf HANDLE und so geht, sondern auf FileHandle, Socket, Event, auf die Begriffe, die die Betriebssysteme gemeinsam haben.