utilizando boost :: filesysystem path desde framework en ios

He estado usando Boost como un marco creado a partir del guión de Pete Goodliffe desde hace bastante time. Funciona genial. Recientemente he llegado a un problema que se puede reproducir al colocar el siguiente código en la vista LoadDid de un controller de vista en un proyecto XCode de lo contrario nuevo:

#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); } 

Esto da como resultado EXC_BAD_ACCESS cuando se destruye el object de la ruta (el problema ocurre en el destructor del miembro de la ruta básica_de la ruta). ¿Alguien más se encuentra con este problema? Todo está construido con el mismo SDK y la configuration de visibilidad es la misma en el proyecto de testing y el marco. Dentro :: existe, la única function llamada ruta es .c_str (), que puedo llamar en mi código sin problema. Pasa el resultado de .c_str () a :: stat, que también puedo llamar con éxito. Parece un desajuste de time de ejecución de algún tipo. ¿Algunas ideas?

El script de Pete Goodliffe aumenta usando gcc, que en el SDK actual es llvm-gcc. El sistema Boost.Build detecta gcc y habilita un set de macros de visibilidad para ciertas cosas, especialmente algunas de las macros de exception utilizadas por la biblioteca del sistema de files cuando GCC está en uso. Por defecto, las aplicaciones iOS creadas usando el SDK actual usarán el clang. Los encabezados de configuration de boost también detectan clang cuando está en uso, y estas macros de visibilidad no se configuran de la misma manera. Esto lleva a algunas advertencias de linker cuando usa clang para build su aplicación contra el impulso, pero usa una biblioteca de impulso construida con gcc, por ejemplo, sobre la visibilidad de vtable y el destructor para las classs de exception en cuestión. Cuando su cadena pasa a una de estas classs, como es probable que ocurra cuando llame al sistema de files :: existe (), verá un locking en el destructor.

Para este ejemplo específico, podría remediar el problema al generar boost con visibilidad = pnetworkingeterminado, pero es improbable que funcione bien para aplicaciones no triviales. Hasta ahora, parece que la mejor apuesta es configurar el comstackdor en Clang ++ para que tenga la misma configuration de visibilidad en efecto para estas classs cuando construye la biblioteca como lo hace cuando construye su aplicación. Aquí está el usuario-config.jam que estoy usando actualmente con (mi versión modificada de) ese script y Xcode 4.2.x. Tenga en count que necesitará replace $ IPHONE_SDKVERSION, ARM_DEV_DIR y SIM_DEV_DIR si no los configura en su script. Para mí, son 5.0 y los directorys bin de los SDK de iphone y simulador, respectivamente:

 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 ; 

Hasta ahora, parece funcionar bien; No he probado lo suficiente para asegurarme por completo que no existen problemas relacionados con el impulso, pero esto parece más fácil que llevar proyectos de iPhone nuevos a llvm-gcc.