2015-06-25 8 views
5

तो मैं ओपनगल, एसडीएल 2, assimp, glm, आदि जैसे अन्य पुस्तकालयों के आधार पर एक सी ++ 11 लाइब्रेरी का निर्माण कर रहा हूं ... केवल समस्या यह है कि उन पुस्तकालयों में से अधिकांश अपने कार्यों को रखते हैं, या वैश्विक नामस्थान में वस्तुओं: यह मेरी कक्षाओं के साथ संघर्ष कर सकता है! (पूर्व। assimp वैक्टर और मेरे वेक्टर वर्ग के लिए ...) तो मैंने वैश्विक नामस्थान "प्रदूषित" करने के लिए वहां उन्हें छोड़ने के बजाय पुस्तकालयों को नामस्थान में डालने का विचार किया।वैश्विक नामस्थान से सी ++ libs को

मैं यह कर के बारे में सोचा:

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

लेकिन मैंने महसूस किया कि वहाँ अभी भी वैश्विक नामस्थान में पुस्तकालय का एक हिस्सा होगा!

यह कैसे प्राप्त करें इस पर कोई सुझाव?

पीएस: मैं libs "लपेट" सकता था, लेकिन यह वास्तव में मनोरंजक नहीं होगा!

+1

क्या मुझे सही समझ आया कि आप ** तृतीय पक्ष ** कोड को नामस्थान में स्थानांतरित करना चाहते हैं और वैश्विक नामस्थान में ** अपना ** कोड छोड़ना चाहते हैं? – Siguza

+0

हाँ, यह है :) – MattMatt

+0

शायद मैं पूछूं कि आप अपने कोड को नामस्थान में क्यों नहीं ले जाते हैं? खासकर जब से आप एक पुस्तकालय बना रहे हैं? आप अन्य लोगों को भी वही परेशानी का कारण बनेंगे जो आप यहां अपने लिए हल करने की कोशिश कर रहे हैं। – Siguza

उत्तर

2

मुझे लगता है कि आप जो चाहते हैं वह सभी पुस्तकालय के कार्यों और कक्षाओं को नामस्थान में रख रहा है।

इस उत्तर में, मैं उदाहरण के लिए gl/gl.h का उपयोग करूंगा।

जहाँ तक मुझे पता है, #include <gl/gl.h> लाइन gl/gl.h से सभी कोडों द्वारा प्रतिस्थापित की जाएगी।

यदि आप एक नाम स्थान (उदाहरण के लिए gl), मैं एक मध्यवर्ती की तरह एक सामग्री के साथ __gl.hpp बुलाया फ़ाइल बनाने चाहिए में gl/gl.h से सभी वर्गों और कार्यों ले जाना चाहते हैं:

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 
} 

फिर, अपने मुख्य फ़ाइल में #include <gl/gl.h>

के बजाय #include "__gl.hpp" का उपयोग करें नोट करें कि मैक्रोज़ को namespace gl में स्थानांतरित नहीं किया जा सकता है, क्योंकि वे मैक्रोज़ हैं।

लेकिन चिंता न करें, क्योंकि:

  • लगभग मैक्रो एक अपरकेस पहचानकर्ता है और लगभग न के मैक्रो लोअरकेस या UpperAndLowerCase या lowerAndUpperCase या lower_case_and_underscore रहे हैं ...

  • एक मैक्रो है पुन: परिभाषित किया जा रहा है, संकलक आपको चेतावनी देगा। तो, आपको नामक मैक्रो के बारे में चिंता करने की ज़रूरत नहीं है।

इस तरह भी windows.h और कुछ अन्य पुस्तकालयों के लिए लागू है, लेकिन यह लगभग C/C++ मानक पुस्तकालय के लिए लागू नहीं किया जा सकता है।

+0

धन्यवाद; एवर के रूप में चिह्नित :) – MattMatt

+0

लेकिन समस्या यह है कि मैं glew का उपयोग करता हूं ... लगभग सबकुछ मैक्रो के रूप में परिभाषित किया जाता है ... – MattMatt

+0

@ मैटमैट मुझे लगता है कि आपको इसके बारे में चिंता करने की ज़रूरत नहीं है। क्योंकि: 1. लगभग मैक्रोज़ COMPLETELY_UPPERCASE (दाएं?) है, क्या कोई गैर-मैक्रो पहचानकर्ता का नाम समान हो सकता है? 2. यदि एक मैक्रो को फिर से परिभाषित किया जा रहा है, तो संकलक आपको चेतावनी देगा। – DMaster

1

जाहिर है, शुद्ध सी पुस्तकालयों के साथ ऐसा करना संभव है। हालांकि, शायद यह करना एक अच्छा विचार नहीं है।

जहां तक ​​मुझे पता है, सी ++ आप जो करने की कोशिश कर रहे हैं उसके लिए उपयोगिता प्रदान नहीं करता है। आपका सबसे अच्छा विकल्प केवल कम से कम सार्वजनिक रूप से उजागर एपीआई के लिए हेडर फ़ाइलों की बजाय स्रोत फ़ाइलों में शामिल करना है। इस तरह से कोई संघर्ष नहीं होना चाहिए, जब तक कि एक ही स्रोत फ़ाइल में शामिल पुस्तकालयों के बीच कोई संघर्ष न हो। यदि अभी भी संघर्ष हैं तो आपको अलग-अलग विवादित शीर्षलेख में उपयोग की जाने वाली वस्तुओं को लपेटना होगा।

इसके अलावा, आप संघर्ष की संभावना को कम करने के लिए अपने स्वयं के वर्गों को नामस्थान के भीतर रखने पर विचार कर सकते हैं।

+0

हाँ मुझे नहीं पता कि मैं नहीं जानता तो एक विकल्प है ... – MattMatt

संबंधित मुद्दे