Auslagern von plattformspezifischem Code

hustbaer

Wutz schrieb:

Aha, du machst Designentscheidungen abhängig von vermeintlichen oder tatsächlichen Performanzabhängigkeiten im Promillebereich, da solltest du dann konsequenterweise gleich in C programmieren, da hast du nämlich gar keinen C++ Overhead.

Mache ich nicht, ich versuche lediglich die Frage des OP zu beantworten. Und dich darauf hinzuweisen dass du ihm einen Vorschlag gemacht hast, den er nicht haben will - worauf er auch schon hingewiesen hat.

Aber mal der Reihe nach.

virtual calls sind eine kaum überwindbare Inlining-Barriere. Die "Performanzabhängigkeiten im Promillebereich" können schnell zu Unterschieden im zweistelligen Prozentbereich werden.
Der OP hat beim Thema Pimpl schon geschrieben dass er das nicht will, weil es zu anderem Maschinencode führen wird als eine naive #ifdef-Orgie. Da virtual calls ganz sicher teurer sind als "einfaches" Pimpl, und vor allem auch zu gänzlich anderem Maschinencode führen werden, gehe ich davon aus dass der OP davon nix wissen will. Warum und ob das Sinn macht ist sein Problem, nicht meins.
Wozu bitte virtual calls? Wenn ich weiss dass das Kompilat X nur auf OS-X laufen wird, und der konkrete Typ hinter dem Zeiger daher in Kompilat X immer der selbe sein wird ... wozu dann bitte virtual? Nur "because we can"? Welches Problem löst es, welchen Vorteil hat man dadurch? Keines und keinen. Also kann ich die konkrete Klasse gleich direkt als Member reinpacken. Ohne Umweg über Zeiger und ohne unnötige virtual Calls. Inlining funktioniert, es kommt Code raus der vermutlich fast identisch mit dem unaufgeräumten #ifdef-Orgien Code ist, alle sind glücklich. Und der Code ist auch nicht mehr oder weniger "OOP" als mit virtual.
Dein Beispiel ist einfach nur Quatsch. virtual + genau eine Implementierung die dann per #ifdef ausgewählt wird. Sorry, aber ... WTF? Irgendwo "OOP" hinschreiben macht aus Quatsch weder objektorientierten Code noch guten Code.