बूस्ट

Question

के समवर्ती रूप से 2 संस्करणों का उपयोग करके मैं आरएचईएल 5.3 का उपयोग कर रहा हूं, जिसे जीसीसी 4.1.2 के साथ भेज दिया गया है और 1.33 को बढ़ावा दिया गया है। कुछ विशेषताएं हैं जो मैं चाहता हूं, जो कि 1.33 को बढ़ावा देने में गायब हैं। इसलिए सोचा ताजा बढ़ावा रिलीज 1.43 में अपग्रेड करना था।

1. क्या यह समेकित रूप से कुछ शीर्षलेख-केवल लाइब्रेरी का उपयोग 1.43 से बढ़ाकर और शेष 1.33 से करना संभव है? उदाहरण के लिए मैं unorded_map का उपयोग करना चाहता हूं, जो कि 1.33 को बढ़ावा देने में अनुपलब्ध है।

2. क्या विभिन्न रिलीज से समवर्ती बाइनरी बूस्ट लाइब्रेरी का उपयोग करना संभव है?

Answer 1

भाग्य का एक सा (और देखभाल के एक बहुत) के साथ

आप कर सकते हैं शायद दूर पूरी तरह से नया हैडर का उपयोग करने के साथ मिलता है। लगभग किसी और चीज के लिए, यह जल्दबाजी में बदसूरत हो सकता है, क्योंकि बूस्ट के कुछ हिस्सों में अन्य भागों का संदर्भ मिलता है, और यदि कुछ v। 1.33 कोड गलती से इसकी निर्भरता के लिए v। 1.43 शीर्षलेख लोड करता है, तो आप एक बहुत अच्छा मौका ले रहे हैं परिणामस्वरूप कुछ समस्याएं प्राप्त करने के लिए - उस बिंदु पर आप जितनी अच्छी उम्मीद कर सकते हैं, वह एक त्वरित, साफ मौत (दुर्घटना) है, लेकिन आप आसानी से बहुत खराब हो सकते हैं (उदाहरण के लिए, चुप डेटा भ्रष्टाचार)।

Answer 2

नहीं - यह कभी नहीं करें!

यह असंभव है, आपको आकस्मिक दुर्घटनाएं होने की संभावना है।

एक ही तरीका है इसे सही ढंग से किया जाना नाम स्थान नाम उपयोग कर रहा है: अर्थात विकल्प बढ़ावा संस्करण में अलग नाम स्थान रखा पैदा करते हैं।

बीसीपी का नवीनतम संस्करण इस विकल्प को प्रदान करता है। तो आप बूस्ट के बजाय boost_1_43 जैसे कुछ का उपयोग करेंगे। लेकिन यह आपके लिए काफी पारदर्शी होगा। लेकिन आपको अभी भी पता होना चाहिए कि आप उसी सीपीपी फ़ाइल में बूस्ट के दो संस्करणों का उपयोग नहीं कर सकते हैं।

इसके अलावा इस चर्चा पर एक नज़र डालें: Creating Library with backward compatible ABI that uses Boost

पसंद आया स्क्रिप्ट नाम स्थान का नाम बदलता है, को परिभाषित करता है और इसलिए शामिल आप वास्तव में

#include <boost/foo.hpp> 
#include <myboost/bar.hpp> 

boost::foo f; 
myboost::bar b; 

बूस्ट बीसीपी इस की अनुमति नहीं है

की तरह बढ़ावा के दो संस्करणों शामिल कर सकते हैं ।

लेकिन फिर भी आपको सावधान रहना चाहिए के रूप में कुछ पुस्तकालयों के बिना बढ़ावा उपसर्ग extern "सी" प्रतीकों निर्यात करते हैं, को बढ़ावा देने :: धागा और बढ़ावा देने :: regex के सी एपीआई (regexec, regcomp)

संपादित

इस तरह के मुद्दे के उदाहरण के रूप में निम्न फ़ाइलें बनाएँ:

a.cpp:

template<typename Foo> 
Foo add(Foo a, Foo b) 
{ 
     return a+b; 
} 


int foo(int x,int y) 
{ 
     return add(x,y); 
} 

b.cpp:

template<typename Foo> 
Foo add(Foo a, Foo b) 
{ 
     return a-b; 
} 


int bar(int x,int y) 
{ 
     return add(x,y); 
} 

परीक्षण।सीपीपी:

#include <iostream> 

int foo(int,int); 
int bar(int,int); 

int main() 
{ 
     std::cout<< foo(10,20) <<" " <<bar(10,20) << std::endl; 
} 

उन्हें संकलित करें:

g++ a.cpp b.cpp test.cpp 

आप उम्मीद करेंगे:

30 -10 

लेकिन आप

30 30 

या

मिलेगा

-10 -10 

लिंकिंग ऑर्डर के आधार पर।

तो दो बढ़ावा संस्करणों का उपयोग कर आप गलती से अन्य को बढ़ावा देने से संकेतों का इस्तेमाल इस कार्यक्रम प्रतीक int add<int>(int,int) में के रूप में ही क्रैश हो सकता है अगर यह अलग संकलन इकाइयों में रखा गया है एक ही प्रतीक भी का संकल्प लिया है।

Answer 3

अद्यतन

मुझे लगता है कि मेरी मूल जवाब लिंकर की क्षमताओं और विकल्प का इस्तेमाल किया के बारे में भी कई धारणाएं बनाता है, और यह अच्छी तरह से पूरी तरह से गलत हो सकता है। आमतौर पर मैं इसे हटा दूंगा, लेकिन चर्चा में कुछ बिंदु हैं जो अन्य उत्तरों में शामिल नहीं हैं।

मुझे एक अच्छी तरह से व्यवहार बंद स्रोत स्रोत लाइब्रेरी बनाने के लिए क्या लगता है इसके लिए प्रभाव पड़ता है।

मूल उत्तर

जब तक आप संकलन चरण के लिए एक संस्करण का उपयोग के रूप में तो आप ठीक होना चाहिए क्योंकि कोड संकलन समय पर उत्पन्न होता है और उत्पन्न प्रतीकों संकलन कदम के दायरे तक ही सीमित होना चाहिए।

मुझे लगता है कि बूस्ट अभी भी कोई लिंक करने योग्य लाइब्रेरी वाला टेम्पलेट लाइब्रेरी नहीं है। यदि ऐसा नहीं है, तो आप तब भी ठीक हैं जब तक आप लाइब्रेरी के एक से अधिक संस्करणों के खिलाफ लिंक नहीं करते हैं।

मैं इस पर गलत हो सकता हूं, लेकिन निहितार्थ यह होगा कि आप अपने आवेदन के लिए परिभाषित संस्करण से बूस्ट के एक अलग संस्करण के खिलाफ बनाई गई किसी भी तृतीय पक्ष लाइब्रेरी का उपयोग नहीं कर सकते हैं। कुछ भी जो मैंने पढ़ा या सुना है, यह भी संकेत देता है कि यह सीमा लागू होती है।

यदि आप अपना खुद का आवेदन बना रहे हैं, तो मैं आपके सभी कोड के लिए बूस्ट के एक संस्करण के साथ रहूंगा। यह एक ही संस्करण नहीं होना चाहिए जो आरएचईएल द्वारा आपूर्ति की जाती है।

अद्यतन

Artyom के उदाहरण के साथ इसकी तुलना में, परिदृश्य के बारे में मैं बात कर रहा हूँ और अधिक इस तरह है:

g++ -c -I/usr/include/boost_1.31 a.cpp 
g++ -c -I/usr/include/boost_1.39 b.cpp 
ar rcs liba.a a.o 
ar rcs libb.a b.o 
g++ -I/usr/include/boost_1.41 test.cpp liba.a libb.a -o test 

... और अब मैं Artyom के दृष्टिकोण को समझते हैं, क्योंकि यह इस पर निर्भर करता लिंकर एक ही लाइब्रेरी फ़ाइल में प्रतीकों को पसंद करता है या नहीं।