Argumentos a favor y en contra de admitir std :: wstring exclusivamente en la biblioteca multiplataforma

Actualmente estoy desarrollando una biblioteca de C++ multiplataforma de la que pretendo ser consciente de Unicode. Actualmente tengo soporte en tiempo de compilación para std :: string o std :: wstring a través de typedefs y macros. La desventaja de este enfoque es que te obliga a usar macros como L("string") y hacer un uso intensivo de plantillas basadas en el tipo de carácter.Argumentos a favor y en contra de admitir std :: wstring exclusivamente en la biblioteca multiplataforma

¿Cuáles son los argumentos a favor y en contra para admitir std :: wstring solamente?

¿Usar std :: wstring obstaculizaría exclusivamente la base de usuarios de GNU/Linux, donde se prefiere la codificación UTF-8?

Fuente

2010-09-06 Oskar N.

Me gusta bastante el enfoque de Python 3: la nueva clase 'str' es unicode, y hay una nueva clase' bytes' para contener secuencias de bytes, y proporciona una manipulación tipo cadena (búsqueda por subcadenas, etc.). Pero solo pueden interpretarse como texto por conversión con una codificación. Por lo tanto, si alguien está planificando, "datos que solo contienen valores de 7 bits", pueden ahorrar memoria utilizando "bytes", pero sus objetos no son compatibles con las cadenas adecuadas. El incómodo problema que veo con esto en C++ es el mismo que ya tienes con wstring, que tienes que convertir literales, y para llamadas a funciones como 'fopen'. –

Mucha gente querría usar unicode con UTF-8 (std :: string) y no con UCS-2 (std :: wstring). UTF-8 es la codificación estándar en muchas distribuciones y bases de datos de Linux, por lo que no respaldarlo sería una gran desventaja. En Linux, cada llamada a una función en su biblioteca con una cadena como argumento requeriría que el usuario convierta una cadena (nativa) UTF-8 en std :: wstring.

En gcc/linux, cada carácter de std :: wstring tendrá 4 bytes mientras que 2 bytes en Windows. Esto puede generar efectos extraños al leer o escribir archivos (y copiarlos de/a diferentes plataformas). Preferiría recomendar UTF-8/std :: string para un proyecto multiplataforma.

Fuente

2010-09-06 12:44:20

Buen punto. También parece que GCC no se comporta bien en un entorno donde std :: string y std :: wstring están mezclados. –

@Oskar N. ¿Qué tipo de problemas? Nunca tuve ningún problema para usar ambos con gcc. – ereOn

por ejemplo, los diferentes tamaños de wchar_t con gcc (4 bytes) y visual studio (2 bytes) –

¿Cuáles son los argumentos a favor y en contra para admitir std :: wstring solamente?

El argumento a favor del uso de caracteres anchos es que puede hacer personajes estrechas todo puede y más.

El argumento en contra de lo que sé que son:

caracteres anchos necesitan más espacio (que no es relevante, los chinos no hacer, en principio, tener más dolores de cabeza más memoria que los estadounidenses tienen)
el uso de caracteres anchos da dolores de cabeza a algunos occidentales que se utilizan para que todos sus personajes quepan en 7 bits (y no están dispuestos a aprender a prestar atención para no mezclar los usos del tipo de carácter con los personajes reales vs. otros usos)

En cuanto a ser flexible: he mantenido una biblioteca (varios kLoC) que podría tratar con caracteres angostos y anchos. La mayor parte fue a través del tipo de carácter que es un parámetro de plantilla, no recuerdo ninguna macro (excepto UNICODE, eso es). No todo era flexible, sin embargo, había algún código allí que finalmente requirió char o wchar_t cadena. (No tiene sentido ampliar las cadenas de clave internas utilizando caracteres anchos).
Los usuarios podían decidir si querían solo compatibilidad con caracteres limitados (en cuyo caso "string" era correcto) o solo compatibilidad de caracteres anchos (que requería el uso de L"string") o si quería apoyar ambos, también (que requirió algo como T("string")).

Fuente

2010-09-06 12:33:38 sbi

¿Tuviste soporte para ambos en la misma compilación, como Boost con su formato y formato? ¿O requirió que los usuarios compilaran una u otra versión de la biblioteca? –

No conozco el formato '/' wformat' de boost, pero todo lo que teníamos en esa lib que los usuarios podían necesitar, ya sea como sistema codificado o Unicode, se templataba en el tipo de carácter. – sbi

Por:

Joel Spolsky escribió The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets. Si te desplazas hacia abajo, encontrarás que su equipo utiliza cadenas de caracteres anchas exclusivamente. Si es lo suficientemente bueno para ellos, es lo suficientemente bueno para ti. ;-)

contra:

Puede que tenga que interactuar con código que no se i18n-conscientes. Pero como cualquier buen escritor de la biblioteca, simplemente esconderás ese desastre detrás de una interfaz fácil de usar, ¿verdad? ¿Derecha?

Fuente

2010-09-06 12:41:38

Parece un gran artículo. Lo leeré más tarde. ¿Menciona algo sobre el uso de std :: wstring en plataformas GNU/Linux? –

es desafortunado, por supuesto, que Joel es principalmente un tipo de Windows y, como tal, su perspectiva es más bien ... miope ... cuando se trata de multiplataforma. Una búsqueda rápida en "linux" y "unix" en la página trajo una sola mención: en la sección histórica. –

Desventaja:

Desde wstring es verdaderamente UCS-2 y no UTF-16. Te daré una patada en la espinilla un día. Y pateará fuerte.

Fuente

2010-09-06 12:50:30 Kugel

Yo diría que usar std::string o std::wstring es irrelevante.

Ninguno ofrece soporte Unicode adecuado de todos modos.

Si necesita internacionalización, necesita la compatibilidad Unicode adecuada y debería comenzar a investigar sobre bibliotecas como la ICU.

Después de eso, es una cuestión de qué uso de codificación, y esto depende de la plataforma en la que se encuentre: ajuste las funciones dependientes del sistema operativo detrás de una capa de abstracción y conviértalas en la capa de implementación cuando corresponda.

No se preocupe por la codificación utilizada internamente por la biblioteca Unicode utiliza (o construir? HUM), que es una cuestión de rendimiento y no debería afectar el uso de la propia biblioteca.

Fuente

2010-09-06 14:50:51

Argumentos a favor y en contra de admitir std :: wstring exclusivamente en la biblioteca multiplataforma

Respuesta

Cuestiones relacionadas