Benutzt hier wer auto_ptr

Columbo

Du solltest statt auto_ptr unique_ptr verwenden. Und das Template-Argument ist der Typ des Pointees.

std::unique_ptr<Interface> pInterface;

Zur Neuzuweisung kannst du reset verwenden.

#ifdef __linux__
    pInterface.reset( new InterfaceLinux );
#else
    pInterface.reset( new InterfaceWindows );
#endif

Wobei ich mich frage, wieso die Zuweisung ins Makro stecken, und nicht den Initializer der Definition...

Der unique pointer erscheint sinnvoll.
Die Initialisierung hab ich aus den defines rausgenommen, da sich durch Codedopplung beim Kompilieren auf den unterschiedlichen Plattformen oftmals Rechtschreibfehler bemerkbar gemacht haben (unter Windows die Variable umbenannt, unter Linux nicht)

also irgendwie rede ich nur noch Unsinn.
Zeit zum schlafen gehen

hustbaer

Du kannst den #ifdef Code auch noch weiter zurückdrängen wenn du willst:

Interface* CreateInterface()
{
    return new
#ifdef __linux__
    InterfaceLinux();
#else
    InterfaceWindows();
#endif
}
...
    std::unique_ptr<Interface> pInterface(CreateInterface());

Oder auch

#ifdef __linux__
#define INTERFACE InterfaceLinux
#else
#define INTERFACE InterfaceWindows
#endif
...

Viele Wege führen nach Rom.

SeppJ

#ifdef __linux__
typedef Interface InterfaceLinux
#else
typedef Interface InterfaceWindows
#endif

Und plötzlich braucht es weder Zeiger noch new.

hustbaer

Oops.
Ja, typedef ist eleganter als #define

Wobei, @SeppJ, ich glaub du hast da was verdreht - ich denke der Name der definiert (Interface) wird steht bei typedef rechts

SeppJ

hustbaer schrieb:

Oops.
Ja, typedef ist eleganter als #define

Wobei, @SeppJ, ich glaub du hast da was verdreht - ich denke der Name der definiert (Interface) wird steht bei typedef rechts

Das kommt davon, wenn man mit einem Auge auf das define-Makro schielt.

knivil

Warum gibt es eine Unterscheidung im Interface zwischen Linux und Windows? Ich dachte, es ist ein Interface, d.h. die Implementation fuer Linux/Windows kann durch das Buildscript realisiert werden, weder define noch typedef ist im Code noetig. Zumindestens gehe ich meist diesen Weg.

hustbaer

@knivil
Er hat eh eine Basisklasse Interface , für die es dann zwei konkrete Implementierungen gibt ( InterfaceLinux und InterfaceWindows ).

Natürlich könnte man diese drei Klassen zusammenfassen, und gleich den Inhalt/Aufbau von Interface per Präprozessor/Build-Skript abhängig vom OS machen.

Bei der typedef Variante sehe ich jetzt aber keinen echten Nachteil.

Abgesehen vielleicht von Sachen wie z.B. wie gut sich das mit diversen Doku-Generatoren (Doxygen, ...) verträgt. Was das angeht wäre es aber vermutlich besser, wenn man eine Klasse Interface hätte, die grösstenteils unabhängig vom OS implementiert ist, und weder per typedef noch per Makro noch per Build-Skript ausgetauscht wird. D.h. entweder zurück zu der Variante die der OP eh schon hat (gemeinsame Basisklasse). Oder eine kleine Wrapper-Klasse die intern abhängig vom OS ein InterfaceLinux oder InterfaceWindows hat, und alle Calls einfach weiterleitet.

knivil

Nun, ich will nur das aktuelle Design kommentieren. Es hat nichts mit auto_ptr zu tun. Echte Nachteile gibt es insgesamt nicht, aber es ist vom Design her unsauber. Laufzeitpolymorphie ueber zwei Ableitungen zu nutzen, wenn niemals beide im Programmfluss instanziert und in einem Kontainer gemeinsam verwaltet werden.