Frage Cross-Platfrom design?

[SeppJ]

Nein, wenn ein Unterschied nach außen sichtbar ist (also am Ende im Header steht), dann ist die Zeit für Präprozessormagie gekommen.

[SoIntMan]

@SeppJ sagte in Frage Cross-Platfrom design?:

Nein, wenn ein Unterschied nach außen sichtbar ist (also am Ende im Header steht), dann ist die Zeit für Präprozessormagie gekommen.

ok aber dann würde ich ja die seperierung des build files und preprocesser magie vermischen.. will man dass hmm.. oder hab ich as nicht verstanden?;)

[SeppJ]

header.h

#if defined(OS_A)
   #include <osa.h>
   typedef OsaType DataType;
#elif defined(OS_B)
   #include <osb.h>
   typedef OsbType DataType;
#endif

void Foo(DataType dt);

impl_a.c

#include "header.h"

void Foo(DataType dt) {...OS-A Zeug...}

impl_b.c

#include "header.h"

void Foo(DataType dt) {...OS-B Zeug...}

Buildscript baut entweder impl_a.c oder impl_b.c, und schert sich (wie es sich für ein Buildscript gehört) nicht um Header.

[SoIntMan]

@SeppJ sagte in Frage Cross-Platfrom design?:

header.h

#if defined(OS_A)
   #include <osa.h>
   typedef OsaType DataType;
#elif defined(OS_B)
   #include <osb.h>
   typedef OsbType DataType;
#endif

void Foo(DataType dt);

impl_a.c

#include "header.h"

void Foo(DataType dt) {...OS-A Zeug...}

impl_b.c

#include "header.h"

void Foo(DataType dt) {...OS-B Zeug...}

Buildscript baut entweder impl_a.c oder impl_b.c, und schert sich (wie es sich für ein Buildscript gehört) nicht um Header.

perfekt, danke dir

[Quiche Lorraine]

@SoIntMan sagte in Frage Cross-Platfrom design?:

#if defined(OS_A)
#include <osa.h>
typedef OsaType DataType;
#elif defined(OS_B)
#include <osb.h>
typedef OsbType DataType;
#endif

Wenn man es ganz schön machen wollte, könnte man hier auch was ähnliches wie HANDLE, HWND oder FILE einführen. Dadurch wäre der Header unabhängig von osa.h und osb.h.

[SeppJ]

@Quiche-Lorraine sagte in Frage Cross-Platfrom design?:

Wenn man es ganz schön machen wollte, könnte man hier auch was ähnliches wie HANDLE, HWND oder FILE einführen. Dadurch wäre der Header unabhängig von osa.h und osb.h.

Stimmt. Für @SoIntMan : Das nennt sich PIMPL bzw. Opaque Pointer und das macht das nochmals viel besser (Auch allgemein, nicht nur für plattformabhängigen Code). https://en.wikipedia.org/wiki/Opaque_pointer

[SoIntMan]

@SeppJ sagte in Frage Cross-Platfrom design?:

Stimmt. Für @SoIntMan : Das nennt sich PIMPL bzw. Opaque Pointer und das macht das nochmals viel besser (Auch allgemein, nicht nur für plattformabhängigen Code). https://en.wikipedia.org/wiki/Opaque_pointer

ja kenn ich benutzt ich an andere stellen;) in diesem platform context hab ich das mal außen or gelassen..

danke

[Finnegan]

@SoIntMan sagte in Frage Cross-Platfrom design?:

@SeppJ sagte in Frage Cross-Platfrom design?:

Stimmt. Für @SoIntMan : Das nennt sich PIMPL bzw. Opaque Pointer und das macht das nochmals viel besser (Auch allgemein, nicht nur für plattformabhängigen Code). https://en.wikipedia.org/wiki/Opaque_pointer

ja kenn ich benutzt ich an andere stellen;) in diesem platform context hab ich das mal außen or gelassen..

PIMPL würd ich auf jeden Fall empfehlen, falls z.B. lediglich für einen Datentyp irgendwo <windows.h> und Konsorten in einem Header mit inkludiert werden müssten. Sonst holt man sich ganz schnell die Krätze ins Haus. In dem Kontext würde ich dann auch den anderen Namen für PIMPL verwenden: compilation firewall

(Sorry, das musste sein. Die oben erwähnten HANDLE, HWND und FILE haben mich getriggert )

[SoIntMan]

@Finnegan sagte in Frage Cross-Platfrom design?:

PIMPL würd ich auf jeden Fall empfehlen, falls z.B. lediglich für einen Datentyp irgendwo <windows.h> und Konsorten in einem Header mit inkludiert werden müssten. Sonst holt man sich ganz schnell die Krätze ins Haus. In dem Kontext würde ich dann auch den anderen Namen für PIMPL verwenden: compilation firewall
(Sorry, das musste sein. Die oben erwähnten HANDLE, HWND und FILE haben mich getriggert )

gibt es auch ein art Opaque typedef, analog zu struct?;)

[Quiche Lorraine]

@SoIntMan sagte in Frage Cross-Platfrom design?:

gibt es auch ein art Opaque typedef, analog zu struct?;)

Ich verstehe die Frage nicht ganz.

Ziel ist es doch Implementierungsdetails zu verbergen. Und solange du dies beherzigst, kannst du Handles frei nach Herzenslust definieren.

Das kann ein Pointer sein, ein Index, ein Bitfeld, ein Typedef, ein Struct,... sein.

Hauptsache die Implementierungsdetails sind nach außen nicht sichtbar.

[Finnegan]

@SoIntMan sagte in Frage Cross-Platfrom design?:

gibt es auch ein art Opaque typedef, analog zu struct?;)

Nein, aber z.B. bei Windows-Typen mache ich das dann meistens so oder ähnlich:

// public header
struct os_data_t;

class Window
{
    ...
    private:
        os_data_t* os_data;
};

// os_a.c
#include <windows.h>

struct os_data
{
    HWND hwnd;
};

...

Wichtig ist halt, im Header das #include <windows.h> zu vermeiden, damit man sich nicht so übles Zeug wie z.B. #define min ... in seinen gesamten Code reinzieht und dann bei jedem std::min(a, b) einen Heidenspaß bekommt ... es gibt zwar #define NOMINMAX für speziell dieses Problem, aber die Header haben auch noch ne Menge anderer Makros, die für Überraschungen sorgen können (z.B. near / far und solche Dinge).

[Quiche Lorraine]

@Finnegan sagte in Frage Cross-Platfrom design?:

Wichtig ist halt, im Header das #include <windows.h> zu vermeiden, damit man sich nicht so übles Zeug wie z.B. #define min ... in seinen gesamten Code reinzieht und dann bei jedem std::min(a, b) einen Heidenspaß bekommt

Spaßig ist auch winsock2.h.

[Finnegan]

@Quiche-Lorraine sagte in Frage Cross-Platfrom design?:

Spaßig ist auch winsock2.h.

Nicht viel mit der gemacht, aber beim groben Überfliegen fallen mir schon ein paar ungünstige Makros auf: SOCKET_ERROR, NO_ADDRESS, NO_DATA, HOST_NOT_FOUND, BIGENDIAN, LITTLEENDIAN (Kollision mit eigenen enums),. Überhaupt, viel zu viele Makros. Ich denke du meinst sowas, oder?