Mezcla de cout y wcout en el mismo progtwig

Estaba leyendo el “Libro de cocina C ++” que tenía el siguiente fragmento:

// cout << s << std::endl; // You shouldn't be able to wcout << ws << std::endl; // run these at the same time 

Si está interesado en ver el ejemplo real, aquí hay un enlace a la página en los libros de Google .

Además, encontré esta pregunta SO que parece indicar que mezclar wcout y cout está bien. ¿Podría alguien explicarme de qué está hablando este comentario?

EDITAR

Del Estándar C ++ [27.4.1]:

Las operaciones de mezcla en los flujos de caracteres anchos y anchos correspondientes siguen la misma semántica que la mezcla de tales operaciones en ARCHIVOS, como se especifica en la Enmienda 1 del estándar ISO C.

De C Estándar [7.19.2]:

Cada stream tiene una orientación. Después de asociar un flujo con un archivo externo, pero antes de que se realicen operaciones en él, el flujo no tiene orientación. Una vez que se ha aplicado una función de entrada / salida de caracteres anchos a una secuencia sin orientación, la secuencia se convierte en una secuencia orientada en gran medida. De forma similar, una vez que se ha aplicado una función de entrada / salida de un byte a un flujo sin orientación, el flujo se convierte en un flujo orientado a bytes. Solo una llamada a la función freopen o la función fwide puede alterar la orientación de una transmisión. (Una llamada exitosa a freopen elimina cualquier orientación).

Las funciones de entrada / salida de bytes no se aplicarán a un flujo orientado en ancho y las funciones de entrada / salida de caracteres anchos no se aplicarán a un flujo orientado a bytes.

Entonces, el estándar parece decir que no debes mezclarlos. Sin embargo, encontré esta cita de este artículo :

Para Visual C ++ 10.0, la función fwide está documentada como no implementada. Y desde un punto de vista práctico, al menos a nivel de salida de líneas enteras, aparentemente funciona bien para mezclar el uso de cout y wcout. Por lo tanto, felizmente, aparentemente Visual C ++ simplemente ignora los requisitos de la norma y no mantiene una orientación de flujo C FILE impracticable.

Y también, con respecto a gcc encontré esta cita de aquí :

Esta es una característica (nueva), no un error, vea libstdc ++ / 11705 y en general busque acerca de la orientación de la secuencia en el estándar C (C99, 7.19.2). En pocas palabras, no se pueden mezclar las E / S orientadas a bytes y de gran amplitud. Por ahora, debido al error señalado en libstdc ++ / 11705, puede obtener algo cercano a sus expectativas llamando a std :: ios :: sync_with_stdio (false); al comienzo de tu progtwig

Cuando se llama a cout o wcout por primera vez, se establece la orientación para stdout . En el caso de cout , stdout convierte en un flujo orientado a bytes, y en el caso de wcout , stdout convierte en un flujo orientado a ancho. Según el estándar C ++ [27.4.1] y el estándar C [7.19.2], una vez que se establece la orientación de una secuencia, no debe llamar a una función que no sea compatible con la orientación de esa secuencia.

No tengo idea.

Al prohibir los hilos, no puede ejecutar dos instrucciones “al mismo tiempo”. Sin embargo, puedes usar cout y wcout en diferentes puntos de tu progtwig. Ambos se asignan a STDOUT y eso es todo … aunque puede que te falles búferes diferentes y obtengas órdenes un tanto inesperadas, en algunos casos.

Aparentemente, cada uno imbuye una orientación en la secuencia “destino” STDOUT , y no está permitido mezclar operaciones en una secuencia que ha sido imbuida con una orientación [C++11: 27.4.1] y [C99: 7.19.2] .

Técnicamente, definitivamente puedes usar las transmisiones estrecha y ancha simultáneamente. Sin embargo, es probable que el resultado sea un error, a menos que haga arreglos para que ambos codifiquen los caracteres de la misma manera. Desafortunadamente, esto viene con la advertencia de que no puede controlar las codificaciones utilizadas por los objetos de transmisión estándar, al menos de forma no portátil. Incluso si la encoding es la misma, debe asegurarse de que los caracteres parciales estén completamente escritos, es decir, cuando menos tenga que vaciar el búfer al cambiar al otro ancho.

La violación de “no debe” de la norma por lo general te lleva al dominio de un comportamiento indefinido. El comportamiento indefinido podría funcionar correctamente en algunas implementaciones.

Como una conjetura: cout y wcout son dos flujos diferentes, y las citas que proporciona no dicen nada sobre cómo la orientación de la secuencia se correlaciona con la orientación del archivo subyacente. ¿Puede ser que las streams silenciosamente reorienten stdout debajo del capó?