2012-02-01 2 views
7

저는 Pete Goodliffe의 스크립트에서 오랫동안 구축 된 프레임 워크로 Boost를 사용해 왔습니다. 훌륭하게 작동합니다.ios의 프레임 워크에서 boost :: filesysystem 경로를 사용합니다.

경로 객체가 파괴 될 때이 EXC_BAD_ACCESS 결과
#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); 
} 

(문제 : 최근에 나는 달리 새로운 Xcode 프로젝트에 뷰 컨트롤러의 viewDidLoad에에 다음 코드를 놓는 방법으로 재생할 수있는 문제를 명중했다 경로의 basic_string 멤버의 소멸자에서 발생 함). 다른 누구도이 문제에 부딪 혔습니까? 모든 것이 동일한 SDK로 구축되고 가시성 설정은 테스트 프로젝트 및 프레임 워크에서 동일합니다. inside :: exists, path에 호출 된 유일한 함수는 .c_str()입니다.이 코드는 문제없이 호출 할 수 있습니다. 그것은 .c_str()의 결과를 :: stat로 넘겨 주며, 성공적으로 호출 할 수도 있습니다. 그것은 일종의 런타임 불일치처럼 보입니다. 어떤 아이디어?

답변

7

Pete Goodliffe의 스크립트는 현재 SDK에서 llvm-gcc 인 gcc를 사용하여 부스트를 만듭니다. Boost.Build 시스템은 gcc를 탐지하고 GCC가 사용 중일 때 파일 시스템 라이브러리가 사용하는 예외 매크로 중 일부를 표시 할 수있는 매크로 집합을 활성화합니다. 기본적으로 현재 SDK를 사용하여 제작 된 iOS 응용 프로그램은 clang을 사용합니다. 부스트 구성 헤더는 사용 중일 때 clang도 감지하며 이러한 가시성 매크로는 같은 방식으로 구성되지 않습니다. clang을 사용하여 부스트에 대비하여 애플리케이션을 빌드 할 때 gcc로 빌드 된 부스트 라이브러리를 사용하면 링커 경고가 표시됩니다 (예 : 문제의 예외 클래스에 대한 vtable 및 소멸자 가시성에 대해 설명합니다. 문자열이이 클래스 중 하나에 전달되면 filesystem :: exists()를 호출 할 때 발생하는 것과 같이 소멸자에서 충돌이 발생합니다.

이 특정 예제의 경우 visibility = default를 사용하여 boost를 빌드하여 문제를 해결할 수 있지만 중요하지 않은 응용 프로그램에서는 제대로 작동하지 않을 수 있습니다. 지금까지는 응용 프로그램을 빌드 할 때처럼 라이브러리를 빌드 할 때 이러한 클래스에 대해 동일한 가시성 설정을 갖도록 컴파일러를 clang ++로 설정하는 것이 가장 좋습니다. 다음은 현재 (수정 된 버전의) 스크립트와 Xcode 4.2.x에서 사용하고있는 user-config.jam입니다. 스크립트에 설정하지 않으면 $ IPHONE_SDKVERSION, ARM_DEV_DIR 및 SIM_DEV_DIR을 바꿔야합니다. 저에게 그들은 5.0이고, 아이폰과 시뮬레이터 SDK의 bin 디렉토리입니다 :

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 
    ; 

지금까지는 잘 작동하는 것 같습니다. 나는 완전히 자신을 확신 할만큼 충분히 테스트하지 못했다. 부스트와 관련된 문제는 없지만, 이것은 새로운 iPhone 프로젝트를 llvm-gcc로 되 돌리는 것보다 쉽다.

관련 문제