2015-06-25 13 views
5

Also ich baue eine C++ 11-Bibliothek basierend auf anderen Bibliotheken wie OpenGL, SDL2, Assimp, Glm, etc ... Das Problem ist nur, dass die meisten dieser Bibliotheken ihre Funktionen platzieren, oder Objekte im globalen Namespace: Dies kann zu Konflikten mit meinen Klassen führen! (zB Assimp-Vektoren und meine Vector-Klasse ...) Also dachte ich daran, die Bibliotheken in einen Namensraum zu stellen, anstatt sie dort zu lassen, um den globalen Namensraum zu "verschmutzen".Platzieren von C++ - Bibliotheken aus dem globalen Namespace

Ich dachte, dies zu tun:

namespace some_name_space 
{ 
    #include <some/kind/of/lib> 
} 

Aber ich erkennen, dass es immer noch ein Teil der Bibliothek im globalen Namespace sein würde!

Irgendwelche Vorschläge, wie dies zu erreichen?

PS: Ich könnte die Bibliotheken "wickeln", aber das wäre nicht wirklich managable!

+1

Habe ich richtig verstanden, dass Sie Code ** von Drittanbietern in einen Namespace verschieben und ** Ihren eigenen ** Code im globalen Namespace hinterlassen möchten? – Siguza

+0

Ja, das ist es :) – MattMatt

+0

Darf ich fragen, warum Sie nicht einfach Ihren eigenen Code in einen Namensraum verschieben? Vor allem, weil Sie eine Bibliothek bauen? Du wirst anderen Menschen die gleichen Probleme bereiten, die du hier selbst lösen willst. – Siguza

Antwort

2

Ich denke, was Sie wollen, ist alle Funktionen und Klassen Bibliothek in einem Namespace platzieren.

In dieser Antwort werde ich gl/gl.h für ein Beispiel verwenden.

Soweit ich weiß, wird die Zeile #include <gl/gl.h> durch den gesamten Code von gl/gl.h ersetzt werden.

wenn Sie alle Klassen und Funktionen von gl/gl.h in einen Namensraum (gl zum Beispiel) bewegen, soll ich eine Zwischendatei __gl.hpp mit einem Inhalt wie genannt erstellen:

namespace gl { 
    using namespace gl; //because gl/gl.h don't know namespace gl 
    #include <gl/gl.h> 
    //#include more and more kind of libraries which use namespace gl 
} 

Dann in Ihrer Hauptdatei Verwenden Sie #include "__gl.hpp" anstelle von #include <gl/gl.h>

Beachten Sie, dass Makros möglicherweise nicht in namespace gl verschoben werden, da es Makros sind.

Aber keine Sorge, denn:

  • Fast Makros haben einen Groß Kennung und fast nicht-Makros sind Klein- oder UpperAndLowerCase oder lowerAndUpperCase oder lower_case_and_underscore ...

  • Wenn ein Makro neu definiert wird der Compiler Sie warnen. Sie müssen sich also nicht um Namensvettern kümmern.

Auf diese Weise ist auch für windows.h und einige andere Bibliotheken, aber es kann nicht für fast C/C++ Standard-Bibliothek angewandt werden.

+0

Danke; als aswer markiert :) – MattMatt

+0

aber problem ist, dass ich glew verwende ... fast alles ist als ein makro definiert ... – MattMatt

+0

@MattMatt ich denke, du brauchst dir keine sorgen darüber. Weil: 1. Fast Makros ist COMPLETELY_UPPERCASE (richtig?), Gibt es irgendeine non-macro Bezeichner könnte den gleichen Namen haben? 2. Wenn ein Makro neu definiert wird, wird der Compiler Sie warnen. – DMaster

1

Offenbar ist das mit reinen C-Bibliotheken möglich. Aber das ist wahrscheinlich keine gute Idee.

Soweit ich weiß, bietet C++ nicht die Dienstprogramme für das, was Sie versuchen zu tun. Die beste Option besteht darin, die Includes nur in die Quelldateien und nicht in die Headerdateien einzufügen, zumindest für die öffentlich zugängliche API. Auf diese Weise sollte es keine Konflikte geben, solange keine Konflikte zwischen den Bibliotheken auftreten, die Sie in einer einzigen Quelldatei enthalten. Wenn es noch Konflikte gibt, müssen Sie die Elemente, die Sie verwenden, in den konfliktbehafteten Header einzeln umbrechen.

Sie können auch Ihre eigenen Klassen in einem Namespace platzieren, um die Wahrscheinlichkeit eines Konflikts zu verringern.

+0

Ja, ich weiß nicht, ob ich habe eine wahl dann ... – MattMatt

Verwandte Themen