आईओएस

Question

पर फ्रेमवर्क से boost :: filesysystem पथ का उपयोग करके मैं पेटी गुडलिफ़ की लिपि से निर्मित कुछ ढांचे के रूप में बूस्ट का उपयोग कर रहा हूं। बहुत अच्छा काम करता है।

#include "boost/filesystem/path.hpp" 
#include "boost/filesystem/operations.hpp" 


- (void)viewDidLoad 
{ 
    [super viewDidLoad]; 
    boost::filesystem::path path("/var/mobile/Applications/.../Documents/somefile.txt"); 
    bool b = boost::filesystem::exists(path); 
} 

यह EXC_BAD_ACCESS में परिणाम है जब पथ वस्तु नष्ट हो जाता है (समस्या: हाल ही में मैं एक समस्या यह है कि एक अन्यथा नया XCode प्रोजेक्ट में एक दृश्य नियंत्रक के viewDidLoad में निम्न कोड छोड़ने के द्वारा reproduced किया जा सकता है हिट पथ के मूल_स्ट्रिंग सदस्य के विनाशक में होता है)। क्या कोई और इस समस्या में चला गया? सब कुछ एक ही एसडीके के साथ बनाया गया है और दृश्यता सेटिंग्स परीक्षण परियोजना और ढांचे पर समान हैं। अंदर :: मौजूद है, पथ पर बुलाया जाने वाला एकमात्र फ़ंक्शन .c_str() है, जिसे मैं बिना किसी समस्या के अपने कोड में कॉल कर सकता हूं। यह .c_str() से :: stat का परिणाम पास करता है, जिसे मैं सफलतापूर्वक कॉल भी कर सकता हूं। ऐसा लगता है कि किसी तरह का रनटाइम मेल नहीं है। कोई विचार?

Answer 1

पीट गुडलिफ़ की लिपि जीसीसी का उपयोग करके बढ़ावा देता है, जो वर्तमान एसडीके में llvm-gcc है। बूस्ट.बिल्ड सिस्टम जीसीसी का पता लगाता है और कुछ चीजों के लिए दृश्यता मैक्रोज़ का एक सेट सक्षम करता है, विशेष रूप से फाइल सिस्टम लाइब्रेरी द्वारा उपयोग किए जाने वाले अपवाद मैक्रोज़ में से कुछ जब जीसीसी उपयोग में है। डिफ़ॉल्ट रूप से, वर्तमान एसडीके का उपयोग करके बनाए गए आईओएस अनुप्रयोग क्लैंग का उपयोग करेंगे। बूस्ट कॉन्फ़िगरेशन हेडर भी उपयोग में होने पर क्लैंग का पता लगाते हैं, और इन दृश्यता मैक्रोज़ को उसी तरह कॉन्फ़िगर नहीं किया जाता है। यह कुछ लिंकर चेतावनियों की ओर जाता है जब आप बूस्ट के खिलाफ अपने आवेदन को बनाने के लिए क्लैंग का उपयोग करते हैं लेकिन जीसीसी के साथ निर्मित बूस्ट लाइब्रेरी का उपयोग करते हैं, उदा। प्रश्न में अपवाद वर्गों के लिए vtable और विनाशक दृश्यता के बारे में। जब आपकी स्ट्रिंग इन कक्षाओं में से किसी एक में गुजरती है, जैसा कि आप फाइल सिस्टम को कॉल करते समय होने की संभावना है :: मौजूद है() आप विनाशक में एक क्रैश देखते हैं।

इस विशिष्ट उदाहरण के लिए, आप दृश्यता = डिफ़ॉल्ट के साथ बढ़ावा देने के द्वारा समस्या का समाधान कर सकते हैं, लेकिन यह गैर-तुच्छ अनुप्रयोगों के लिए अच्छी तरह से काम करने की संभावना नहीं है। अब तक, ऐसा लगता है कि कंपाइलर को क्लैंग ++ में सेट करना सबसे अच्छा शर्त है ताकि जब आप अपना एप्लिकेशन बनाते समय लाइब्रेरी बनाते हैं तो इन वर्गों के लिए आपके पास समान दृश्यता सेटिंग होती है। यहां उपयोगकर्ता-config.jam है, मैं वर्तमान में उस स्क्रिप्ट और एक्सकोड 4.2.x के साथ (मेरे संशोधित संस्करण) का उपयोग कर रहा हूं। ध्यान दें कि यदि आप अपनी स्क्रिप्ट में उन्हें सेट नहीं कर रहे हैं तो आपको $ IPHONE_SDKVERSION, ARM_DEV_DIR और SIM_DEV_DIR को प्रतिस्थापित करने की आवश्यकता होगी। मेरे लिए, वे 5.0 और iphone और सिम्युलेटर SDK का बिन निर्देशिका क्रमश: कर रहे हैं:

using darwin : $IPHONE_SDKVERSION~iphone 
    : ${ARM_DEV_DIR}clang++ 
    : <striper> 
    <compileflags>"-arch armv7 -fvisibility=hidden -fvisibility-inlines-hidden $EXTRA_CPPFLAGS" 
    : <architecture>arm <target-os>iphone 
    ; 
using darwin : $IPHONE_SDKVERSION~iphonesim 
    : ${SIM_DEV_DIR}clang++ 
    : <striper> 
    <compileflags>"-arch i386 -fvisibility=hidden -fvisibility-inlines-hidden $EXTRA_CPPFLAGS" 
    : <architecture>x86 <target-os>iphone 
    ; 

अब तक, कि अच्छी तरह से काम कर रहा है; मैंने पूरी तरह से आश्वस्त करने के लिए पर्याप्त परीक्षण नहीं किया है कि बूस्ट से कोई समस्या नहीं है, लेकिन यह नई आईफोन परियोजनाओं को वापस लेवल-जीसीसी में ले जाने से आसान लगता है।