2012-06-25 10 views
8

El siguiente código funciona bien en Linux, pero genera una excepción en OS X 10.7:lugares poniente en OS X se bloquea

#include <iostream> 
#include <locale> 
#include <stdexcept> 

int main() try { 
    std::locale::global(std::locale("")); 
    std::cout << "Using locale: " << std::locale().name() << "\n"; 
} 
catch (std::runtime_error const& e) { 
    std::cout << e.what() << "\n"; 
    return 1; 
} 

La salida en OS X es:

locale::facet::_S_create_c_locale nombre no válido

Sin embargo, la norma dice explícitamente que

El conjunto de valores de argumento de cadena válidos es "C", "" y cualquier valor definido por la implementación.

Por lo tanto, cualquier causa del comportamiento anterior está violando el estándar.

El compilador utilizado es clang ++ 3.1 (tags/Apple/clang-318.0.58); También lo probé con GCC 4.7, instalado a través de Homebrew, con el mismo resultado.

¿Pueden otras personas validar este problema? ¿Qué lo causa? ¿Estoy haciendo algo mal? ¿Es esto un error en OS X?

(Tal vez esto relates to another xlocale problem pero los errores son en realidad completamente diferente.)

+0

Creo que esto es (casi) un duplicado de [esta pregunta] (http://stackoverflow.com/questions/1745045/stdlocale-breakage-on-macos-10-6-with-lang-en-us- utf-8) ... –

+0

@EitanT ¡Buen descubrimiento, es (un * exacto * duplicado)! Gracias. –

+0

No creo que estés usando xlocale. Creo que su problema es con libstdC++, que usa una biblioteca de soporte de locale diferente (que aparentemente no es compatible con OS X, como la pregunta que EitanT vincula a los estados). Creo que si cambias a libC++, tu programa funcionará. Aunque como mi pregunta detalla, hay problemas con algunas configuraciones regionales en libC++, debido a errores en xlocale. – bames53

Respuesta

2

No creo que estés usando xlocale. Creo que su problema es con libstdC++, que usa una biblioteca de soporte de locale diferente que no es compatible con OS X, ya que la pregunta EitanT se vincula a los estados.

Si cambia a libC++ su programa funcionará.

0

El póster de arriba correcto ... el problema es con libstdC++. Quería agregar mi respuesta porque no es fácil cómo hacer que OS X se vincule con libC++ y tardé más de una hora en descubrirlo.

Invocando el compilador/enlazador por g++ -libstd=libc++ o por clang++ -libstd=libc++ o por el alias c++ -libstd=libc++ todos fallarán.

La solución para la elaboración de programas sencillos desde la línea de comandos en lugar de jugar con la sobrecarga añadida de Xcode es permitir Xcode manejar la vinculación mediante el comando xcrun clang++ -stdlib=libc++

xcrun permite Xcode para gestionar la cadena de herramientas y la voluntad construir un ejecutable exitoso donde cout.imbue(locale(foo)) funcionará con éxito.

+3

Realmente puedes usar libC++ muy bien con 'clang ++' cuando haces lo siguiente: 'export CXX =" clang ++ - $ cxxver -stdlib = libC++ "' y 'export CXXFLAGS =" - nostdinC++ -isystem/usr/local/lib/llvm - $ cxxver/include/C++/v1 "' (para un '$ cxxver' apropiado). No * * confío en Xcode en ninguna parte del proceso, en particular después de haber instalado una versión más nueva de Clang a través de Homebrew. –

+0

Konrad, agradezco la ayuda, pero ¿puede ayudar a un novato y explicar un poco más lo que hacen esos comandos? – user3176017

+2

Los comandos 'export' establecen variables de entorno en su terminal. [Familiarícese con las variables 'CXX' y' CXXFLAGS'] (http://www.gnu.org/software/make/manual/make.html), son un poco importantes para el desarrollo de C++ en Unix. Ahora, las opciones establecidas con estas variables son '-nostdinC++', que inhabilita el uso de la implementación de la biblioteca estándar predeterminada. '-libC++' le dice a clang que use libC++ en lugar del predeterminado (libstdC++), y '-system ...' le dice a clang dónde encontrarlo. –