wcout, wprintf() only print English

[Ioannis Vranos]

[...]Instead of messing with these details, perhaps we should accept
that the C subset setlocale() function defined in <clocale> is simpler
(and thus better)?


The following code works:


#include <iostream>
#include <clocale>
#include <string>
#include <cstdlib>


int main()
{
using namespace std;

if (!setlocale( LC_ALL, "greek" ))
{
cerr<< "NULL returned!\n";

return EXIT_FAILURE;
}


wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}

If the locale name "greek" means an eight-bit character set is used you
don't need to use wstring, wcin and wcout at all? What character set do
you actually plan to use in your program?

Boris

I am only experimenting with the wide character support. Is there any
possibility the "greek" locale to be only a 8-bit one? And if it is, how
can it also display english (latin characters)? By using something like
ASCII extended (0-127 latin characters and 128-255 greek characters)?


"locale -a" also displays the following greek encodings:


el_GR
el_GR.iso88597
el_GR.utf8



The following also works:


#include <iostream>
#include <clocale>
#include <string>
#include <cstdlib>

int main()
{
using namespace std;

if (!setlocale( LC_ALL, "el_GR.utf8" ))
{
cerr<< "NULL returned!\n";

return EXIT_FAILURE;
}

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}


[john@localhost src]$ ./foobar-cpp
Δοκιμαστικό
Δοκιμαστικό
[john@localhost src]$


but the following doesn't:

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


int main()
{
using namespace std;

wcout.imbue(locale("el_GR.utf8"));

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}

[john@localhost src]$ ./foobar-cpp
Δοκιμαστικό

[john@localhost src]$

 

[Ioannis Vranos]

I managed to make it work under the newer C++ facilities, after having a
look in ISO C++ example code:


The following codes work:


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


int main()
{
using namespace std;

locale::global(locale("greek"));

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}



[john@localhost src]$ ./foobar-cpp
Δοκιμαστικό
Δοκιμαστικό
[john@localhost src]$


along with el_GR, el_GR.iso88597, el_GR.utf8. For example the following
code also works:


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


int main()
{
using namespace std;

locale::global(locale("el_GR.utf8"));

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}


[john@localhost src]$ ./foobar-cpp
Δοκιμαστικό
Δοκιμαστικό
[john@localhost src]$

 

[Jeff Schwab]

I filed a bug in GCC Bugzilla:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353

Ahh, sanity from the Gnu.

May anyone explain me how should I apply the suggested solution
"sync_with_stdio (false)", and the fstream suggested solution to the
following failing code?

fstream has nothing to do with it. The Gnu developer just thought you
might have used sync_with_stdio before with file streams. What he means
is that before you do any I/O, you should make a call like this:

std::ios_base::sync_with_stdio(false);

The following program, as far as I can tell, works find on my system.

#include <iostream>
#include <locale>

int main()
{
std::ios_base::sync_with_stdio(false);

std::wcout.imbue(std::locale("el_GR.UTF-8"));

std::wcout<< L"Δοκιμαστικό μήνυμα\n";
std::wcout.flush();
}

 

[Ioannis Vranos]

Ahh, sanity from the Gnu.



fstream has nothing to do with it. The Gnu developer just thought you
might have used sync_with_stdio before with file streams. What he means
is that before you do any I/O, you should make a call like this:

std::ios_base::sync_with_stdio(false);

The following program, as far as I can tell, works find on my system.

#include <iostream>
#include <locale>

int main()
{
std::ios_base::sync_with_stdio(false);

std::wcout.imbue(std::locale("el_GR.UTF-8"));

std::wcout<< L"Δοκιμαστικό μήνυμα\n";
std::wcout.flush();
}

Yes it works OK here too. How does desynchronizing with stdio makes the
program work?

 

[Ioannis Vranos]

Correction:

I managed to make it work under the newer C++ facilities, after having a
look in ISO C++ example code:


The following codes work:


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


int main()
{
using namespace std;

locale::global(locale("greek"));

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}

Although the above works, I think the correct version is the following:


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


int main()
{
using namespace std;

locale::global(locale("greek"));

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

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}

 

[Jeff Schwab]

Yes it works OK here too. How does desynchronizing with stdio makes the
program work?

No idea. From your other post, the code appears to work without the
sync call.

sync_with_stdio(false) means that the C++ I/O streams no longer have to
coordinate their actions with the C I/O streams: stdin, stdout, and
stderr. The Gnu developer seemed to imply that the C I/O streams had
some fundamental limitation that prevented them to support multi-byte
text. His solution was to "untie" wcout from stdout.

 

[Boris]

[...]I am only experimenting with the wide character support. Is there
any possibility the "greek" locale to be only a 8-bit one? And if it is,
how can it also display english (latin characters)? By using something
like ASCII extended (0-127 latin characters and 128-255 greek
characters)?

You might want to use this character set:
http://en.wikipedia.org/wiki/ISO/IEC_8859-7

Boris

 

[Ioannis Vranos]

No idea. From your other post, the code appears to work without the
sync call.

sync_with_stdio(false) means that the C++ I/O streams no longer have to
coordinate their actions with the C I/O streams: stdin, stdout, and
stderr. The Gnu developer seemed to imply that the C I/O streams had
some fundamental limitation that prevented them to support multi-byte
text. His solution was to "untie" wcout from stdout.

The bottom line of this, as far as I can understand, is that my & your
GCC has a bug for standard stream imbue() specialisations when
locale::global() is not specified while the C++ standard I/O is
synchronized with the C subset standard I/O.

When we desync them, the standard stream imbue() locale specialisations
work normally.

 

[Ioannis Vranos]

The bottom line of this, as far as I can understand, is that my & your
GCC has a bug for standard stream imbue() specialisations when
locale::global() is not specified while the C++ standard I/O is
synchronized with the C subset standard I/O.

When we desync them, the standard stream imbue() locale specialisations
work normally.

Actually GNU do not consider it as a bug, but as an
implementation-defined behaviour. As he said:

"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".

 

[Jeff Schwab]

Actually GNU do not consider it as a bug, but as an
implementation-defined behaviour. As he said:

"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".

That's enough for me, but I rarely need multi-byte characters. Please
post back to c.l.c++ if you com across any other interesting issues
related to languages other than English.

 

[kasthurirangan.balaji]

The bottom line of this, as far as I can understand, is that my & your
GCC has a bug for standard stream imbue() specialisations when
locale::global() is not specified while the C++ standard I/O is
synchronized with the C subset standard I/O.

When we desync them, the standard stream imbue() locale specialisations
work normally.- Hide quoted text -

- Show quoted text -

may i suggest usage of wcin.imbue(locale("greek")) as well as
wcout.imbue(locale("greek")).Looks like your program worked when
global locale was set. But the program has locale imbued only to wcout
and not to wcin. Setting the global locale sets both wcin and wcout to
that locale. Referring C++ standard I/O streams & locales by Langer/
Kreft, different locales can be imbued to different streams and still
all the streams can be used without crossing each other. Currently i
am handicapped to try this since our environment has only english
locale.

Moreover sync_with_stdio has something to do with performance, again
referring Langer/Kreft.

 

[James Kanze]

On Feb 24, 10:52 pm, Ioannis Vranos

[...]

Actually GNU do not consider it as a bug, but as an
implementation-defined behaviour. As he said:

"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".

That's a wierd statement. wcin inputs wide characters as bytes,
so unless wchar_t is the same size as char, it has to convert
somehow. And I don't see any relationship between the
conversion (which is required to depend on the imbued locale)
and stdio (which is required by the C standard to convert wide
character I/O according to the global locale).

 

[James Kanze]

On Feb 25, 5:32 am, (e-mail address removed) wrote:

[...]

Moreover sync_with_stdio has something to do with performance,
again referring Langer/Kreft.

sync_with_stdio basically means that mixing stdio and iostream
on the same stream (with cin==stdin, etc.) will work. It's
actual effect is that anytime you do I/O on an iostream, the
streambuf will first call fflush() on stdout, and vice versa.
Or behave as if that were the case.

If the implementation of stdio knows about the implementation of
iostream, and vice versa, this is relatively easy to handle,
without any significant loss of performance. If the two are
independent (usually the case, and definitely the case with g++,
where stdio is normally provided by the platform), stdio isn't
going to sync with the iostream, so iostream basically has to
call fflush before each operation (which shouldn't cost much if
there hasn't actually been any output), and sync after every
operation (which can be very, very expensive in terms of time).

Of course, none of this has anything to do with how the iostream
transcodes its input or output.

 

[Ioannis Vranos]

may i suggest usage of wcin.imbue(locale("greek")) as well as
wcout.imbue(locale("greek")).Looks like your program worked when
global locale was set. But the program has locale imbued only to wcout
and not to wcin. Setting the global locale sets both wcin and wcout to
that locale. Referring C++ standard I/O streams & locales by Langer/
Kreft, different locales can be imbued to different streams and still
all the streams can be used without crossing each other. Currently i
am handicapped to try this since our environment has only english
locale.

Moreover sync_with_stdio has something to do with performance, again
referring Langer/Kreft.

If you mean this:

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


int main()
{
using namespace std;

// locale::global(locale("greek"));

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

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}


It doesn't work:


[john@localhost src]$ ./foobar-cpp
Δοκιμαστικό

[john@localhost src]$



If I uncomment the commented line, it works:

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


int main()
{
using namespace std;

locale::global(locale("greek"));

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

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}


[john@localhost src]$ ./foobar-cpp
Δοκιμαστικό
Δοκιμαστικό
[john@localhost src]$

 

[Ioannis Vranos]

may i suggest usage of wcin.imbue(locale("greek")) as well as
wcout.imbue(locale("greek")).Looks like your program worked when
global locale was set. But the program has locale imbued only to wcout
and not to wcin. Setting the global locale sets both wcin and wcout to
that locale. Referring C++ standard I/O streams & locales by Langer/
Kreft, different locales can be imbued to different streams and still
all the streams can be used without crossing each other. Currently i
am handicapped to try this since our environment has only english
locale.

Moreover sync_with_stdio has something to do with performance, again
referring Langer/Kreft.

If you mean this:

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


int main()
{
using namespace std;

// locale::global(locale("greek"));

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

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}


It doesn't work:


[john@localhost src]$ ./foobar-cpp
Δοκιμαστικό

[john@localhost src]$



If I uncomment the commented line, it works:

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


int main()
{
using namespace std;

locale::global(locale("greek"));

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

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
}


[john@localhost src]$ ./foobar-cpp
Δοκιμαστικό
Δοκιμαστικό
[john@localhost src]$

This also works:

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

[john@localhost src]$ ./foobar-cpp
Δοκιμαστικό
Δοκιμαστικό
[john@localhost src]$


In summary, the locale specialisations work only either when we use the
locale::global() statement, or we use the
std::ios_base::sync_with_stdio(false); statement. I have the feeling
this is a bug and not an implementation-defined behaviour.

 

[kasthurirangan.balaji]

(e-mail address removed) wrote:

If you mean this:

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

int main()
{
    using namespace std;

  //  locale::global(locale("greek"));

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

    wstring ws;

    wcin>> ws;

    wcout<< ws<< endl;
}

It doesn't work:

[john@localhost src]$ ./foobar-cpp
Äïêéìáóôéêü

[john@localhost src]$

If I uncomment the commented line, it works:

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

int main()
{
    using namespace std;

    locale::global(locale("greek"));

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

    wstring ws;

    wcin>> ws;

    wcout<< ws<< endl;
}

[john@localhost src]$ ./foobar-cpp
Äïêéìáóôéêü
Äïêéìáóôéêü
[john@localhost src]$

This also works:

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

}

[john@localhost src]$ ./foobar-cpp
Äïêéìáóôéêü
Äïêéìáóôéêü
[john@localhost src]$

In summary, the locale specialisations work only either when we use the
locale::global() statement, or we use the
std::ios_base::sync_with_stdio(false); statement. I have the feeling
this is a bug and not an implementation-defined behaviour.- Hide quoted text -

- Show quoted text -

could you pls try without global locale!!!

i am not sure how the conclusion was arrived - use
std::ios_base::sync_with_stdio(false). Shall update if i come across
something similar.

Thanks,
Balaji.

 

[kasthurirangan.balaji]

(e-mail address removed) wrote:
may i suggest usage of wcin.imbue(locale("greek")) as well as
wcout.imbue(locale("greek")).Looks like your program worked when
global locale was set. But the program has locale imbued only to wcout
and not to wcin. Setting the global locale sets both wcin and wcout to
that locale. Referring C++ standard I/O streams & locales by Langer/
Kreft, different locales can be imbued to different streams and still
all the streams can be used without crossing each other. Currently i
am handicapped to try this since our environment has only english
locale.
Moreover sync_with_stdio has something to do with performance, again
referring Langer/Kreft.
If you mean this:
#include <iostream>
#include <locale>
#include <string>
int main()
{
    using namespace std;
  //  locale::global(locale("greek"));
    wcin.imbue(locale("greek"));
    wcout.imbue(locale("greek"));
    wstring ws;
    wcin>> ws;
    wcout<< ws<< endl;
}
It doesn't work:
[john@localhost src]$ ./foobar-cpp
Äïêéìáóôéêü
[john@localhost src]$
If I uncomment the commented line, it works:
#include <iostream>
#include <locale>
#include <string>
int main()
{
    using namespace std;
    locale::global(locale("greek"));
    wcin.imbue(locale("greek"));
    wcout.imbue(locale("greek"));
    wstring ws;
    wcin>> ws;
    wcout<< ws<< endl;
}
[john@localhost src]$ ./foobar-cpp
Äïêéìáóôéêü
Äïêéìáóôéêü
[john@localhost src]$

This also works:

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

}

[john@localhost src]$ ./foobar-cpp
Äïêéìáóôéêü
Äïêéìáóôéêü
[john@localhost src]$

In summary, the locale specialisations work only either when we use the
locale::global() statement, or we use the
std::ios_base::sync_with_stdio(false); statement. I have the feeling
this is a bug and not an implementation-defined behaviour.- Hide quoted text -

- Show quoted text -

could you pls try without global locale!!!

the post didn't show your other work - already done for this, atleast
in my browser or maybe i didn't have a proper look at it. hence
suggested this.

It looks wierd. By the way i guess, we need to initialize the locale
first before use(one try could be locale("C") though this should be by
default) - which i do not know if the standard specifies that way or
its the implementation.

Thanks,
Balaji.

 

[Gerhard Fiedler]

Thanks. I'll give it a try myself. (Of course, the executables it
generates will also require VMWare to run, but it will allow at least
verifying that my code compiles with VC++ before trying to port it to
Windows.)

How will the generated executables require VMware to run? If you generate
executables in such an environment, they'll run on any of the Windows
platforms supported by your code and compilation, whether under VMware or
not.

Gerhard

 

[James Kanze]

On 2008-02-24 10:51:32, James Kanze wrote:

How will the generated executables require VMware to run?

How will they not? VC++ will certainly still produce a Windows
executable, not a Linux executable.

If you generate executables in such an environment, they'll
run on any of the Windows platforms supported by your code and
compilation, whether under VMware or not.

If I had a Windows platform handy, I'd run VC++ on it. If I
have to run it under VMware, it's because I don't have a Windows
platform available otherwise.

 

[James Kanze]

On Feb 25, 4:53 pm, Ioannis Vranos <[email protected]>
wrote:

[...]

i am not sure how the conclusion was arrived - use
std::ios_base::sync_with_stdio(false).

What does sync_with_stdio have to do with the locales? With the
exception of possible performance issues, and when buffers are
getting flushed (which is unspecified anyway), sync_with_stdio
should have no impact as long as all I/O actually is done with
iostream. If this is not the case, there's a problem with the
implementation.