Created attachment 15217 [details]
The main.ii file produced by  -save-temps option

This is the file created by the 

g++ -v -save-temps -ansi -pedantic-errors -Wall main.cc -o foobar-cpp 

command, on the non-working code.

Created attachment 15218 [details]
The produced main.s file

The main.s file produced by "g++ -v -save-temps -ansi -pedantic-errors -Wall main.cc -o foobar-cpp"

Not a bug, given our implementation-defined behavior: the various cin / wcin, streams are by default synced with stdio (per the standard requirements) and thus not converting. You can either call sync_with_stdio(false) before any I/O or use converting stream, like fstreams.

Created attachment 15219 [details]
Screenshot of the standard I/O of the working code and of the non-working code.

This screenshot shows the I/O of the working code and of the non-working code respectively.

sync_with_stdio (false) doesn't work. Actually it crashes the code.

Check the screenshot I have attached in the latest attachment, to see the difference between the C++ working code and the C++ non-working code.

sync_with_stdio(false) works, and is tested dozens of times a day in our testsuites. And that is only half of my answer. Please understand what I said, study the details of the ISO C++ Standard and then come back.

I am sorry for insisting on this, but I think there is an issue, and I want the best for GCC. So please have a look at the messages of this link:

http://tinyurl.com/384u3n and use Unicode (UTF-8) character encoding in your browser, to see the issues.


Thanks.

Summary of the case:

What doesn't work:

#include <iostream>
#include <locale>
#include <string>


int main()
{
    using namespace std;



    wcin.imbue(locale("greek"));
    wcout.imbue(locale("greek"));

    wstring ws;

    wcin>> ws;

    wcout<< ws<< endl;
} 


What works (under 2 conditions):

1. Only when "locale::global()" statement is used:

#include <iostream>
#include <locale>
#include <string>


int main()
{
    using namespace std;

    locale::global(locale("en_US"));

    wcin.imbue(locale("greek"));
    wcout.imbue(locale("greek"));

    wstring ws;

    wcin>> ws;

    wcout<< ws<< endl;
} 


2. Only when "ios_base::sync_with_stdio(false)" statement is used.

#include <iostream>
#include <locale>
#include <string>


int main()
{
    using namespace std;

    ios_base::sync_with_stdio(false);

    wcin.imbue(locale("greek"));
    wcout.imbue(locale("greek"));

    wstring ws;

    wcin>> ws;

    wcout<< ws<< endl;
} 

Maybe we can improve the behavior when the stdio is synced, that is we can transcode each wchar_t and sync after each transcoding. Very likely, you can also simulate that behavior right now by using sync_with_stdio(false) + a custom single-char I/O buffer. In any case, any enhancement will be implemented only when the binary compatibility will be broken.

Note, anyway, that there is a serious blocker to any enhancement in this area (and of course it explains the current behavior): if wcin & co are converting, they deal with the underlying stream as a narrow-character oriented stream. But when the stream is synced it must be possible to mix char-by-char with wchar_t C stdio operations, which require a wide-character orientation of the stream, whereas, per C99 7.19.2, the orientation of a stream cannot be changed after opening.

About my last reply: I checked, and within the current implementation of the underlying I/O the last issue (per libstdc++/9662) doesn't exist anymore, in other terms, when sync_with_stdio(false), C++ I/O on wcin/wcout doesn't change the orientation of the stream to byte (i.e, fwide < 0). Good.

We have re-investigate all the other reasons that led to the separate non-converting synced (default) implementation of wcin & co...

*** Bug 37298 has been marked as a duplicate of this bug. ***

*** Bug 37673 has been marked as a duplicate of this bug. ***

*** Bug 33852 has been marked as a duplicate of this bug. ***

Why can't wcout simply convert to the selected encoding, and append the results to the cout buffer, as if the converted string had been directly output to cout?

I'm not sure about the implementation details, but I fail to see how anything could prevent adopting this rather obvious solution.

Of course, if cout is in the middle of the byte sequence of a character, this will not result in sensible output, but that is user error and I fail to see how such use could be made meaningful.

BTW, doesn't cout share the stdout buffer via the GNU libio FILE/iostream sharing mechanism, making sync_with_stdio do nothing anyway?

We may make progress on this for 4.6.0, but I don't make promises. If, after having studied the relevant bits of the Standard and the current implementation of these features (I remind you that this is Free Software, thus no mysteries, no need for black-box thinking) I would recommend going ahead and proposing a patch (after having filed the required Copyright Assignment). Thanks.