469,572 Members | 1,201 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,572 developers. It's quick & easy.

Mixing setlocale() and c++ locales

I was working with a co-worker the other day to work through the
process of formatting numeric values by imbueing C++ iostreams with
locales. His program's initialisation code had a call to
setlocale("",LC_ALL) which I believe sets up locale information for the
C run time library but is not supposed to effect the C++ run time.
What we found, however, was that, with this function call in place, the
C++ iostreams were formatting floating point values according to the US
convention (commas as a thousands separator and periods as a decimal)
even though the stream was imbued with a different locale (Brasilian
Portuguese in our case). We found that, if we removed the above
mentioned call that the iostream formatting worked aas we expected. My
question is whether this interaction is a bug or is it rather an
unfortunate but planned side effect that comes from mixing the "C"
and C++ locales models?

Regards,

Jon Trauntvein

Nov 17 '05 #1
3 2570
J Trauntvein wrote:
I was working with a co-worker the other day to work through the
process of formatting numeric values by imbueing C++ iostreams with
locales. His program's initialisation code had a call to
setlocale("",LC_ALL) which I believe sets up locale information for the
C run time library but is not supposed to effect the C++ run time.
What we found, however, was that, with this function call in place, the
C++ iostreams were formatting floating point values according to the US
convention (commas as a thousands separator and periods as a decimal)
even though the stream was imbued with a different locale (Brasilian
Portuguese in our case). We found that, if we removed the above
mentioned call that the iostream formatting worked aas we expected. My
question is whether this interaction is a bug or is it rather an
unfortunate but planned side effect that comes from mixing the "C"
and C++ locales models?


Do you have a test case? The following prints "1,234" for me on VC7.1:

#include <iostream>
#include <locale>
#include <locale.h>

int main()
{
std::locale loc("Portuguese_Brazil");
std::cout.imbue(loc);
setlocale(LC_ALL, "");
std::cout << 1.234 << '\n';
}

Moving the setlocale call to the start makes no difference. The C and
C++ locale systems are synchronized to a degree. See
http://www.dinkumware.com/manuals/re...e2.html#locale
for some info on this, or check the C++ standard.

Tom
Nov 17 '05 #2

Tom Widmer wrote:
J Trauntvein wrote:
I was working with a co-worker the other day to work through the
process of formatting numeric values by imbueing C++ iostreams with
locales. His program's initialisation code had a call to
setlocale("",LC_ALL) which I believe sets up locale information for the C run time library but is not supposed to effect the C++ run time.
What we found, however, was that, with this function call in place, the C++ iostreams were formatting floating point values according to the US convention (commas as a thousands separator and periods as a decimal) even though the stream was imbued with a different locale (Brasilian Portuguese in our case). We found that, if we removed the above
mentioned call that the iostream formatting worked aas we expected. My question is whether this interaction is a bug or is it rather an
unfortunate but planned side effect that comes from mixing the "C" and C++ locales models?
Do you have a test case? The following prints "1,234" for me on

VC7.1:
#include <iostream>
#include <locale>
#include <locale.h>

int main()
{
std::locale loc("Portuguese_Brazil");
std::cout.imbue(loc);
setlocale(LC_ALL, "");
std::cout << 1.234 << '\n';
}

Moving the setlocale call to the start makes no difference. The C and C++ locale systems are synchronized to a degree. See
http://www.dinkumware.com/manuals/re...e2.html#locale
for some info on this, or check the C++ standard.

Tom


I just tried the following code:

#include <iostream>
#include <locale.h>
int main()
{
double const val = 123456.789;

setlocale(LC_ALL,"");
std::cout.imbue(std::locale("Portuguese_Brazil"));
std::cout << val << std::endl;
return 0;
} // main
This produces the behaviour that I described provided that the
operating system regional settings are set to Brasilian Portuguese. It
does not appear when the regional locale is set to US English.
Commenting out the setlocale() call produces the correct behaviour.

Regards,

Jon Trauntvein

Nov 17 '05 #3
J Trauntvein wrote:
I just tried the following code:

#include <iostream>
#include <locale.h>
int main()
{
double const val = 123456.789;

setlocale(LC_ALL,"");
std::cout.imbue(std::locale("Portuguese_Brazil"));
std::cout << val << std::endl;
return 0;
} // main
This produces the behaviour that I described provided that the
operating system regional settings are set to Brasilian Portuguese. It
does not appear when the regional locale is set to US English.
Commenting out the setlocale() call produces the correct behaviour.


Ok, I managed to get the same behaviour. Note that changing:
setlocale(LC_ALL,"");
to
std::locale::global(std::locale(""));
gives the same effect without using the C library.

Fiddling around with the regional settings and the code, I didn't work
out the the logic behind the way it works (or, rather, doesn't work).
I'd recommend just removing the call to setlocale if at all possible.
Further, I'd recommend posting in microsoft.public.vc.stl, where
P.J.Plauger and Pete Becker (both of Dinkumware, the standard library
supplier for VC) are likely to see it, and hopefully tell you how it
works, and how to fix your problem.

Tom

Nov 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by transam | last post: by
3 posts views Thread by Ksenia Marasanova | last post: by
1 post views Thread by Mathieu Malaterre | last post: by
3 posts views Thread by Damien Elmes | last post: by
3 posts views Thread by Schraalhans Keukenmeester | last post: by
reply views Thread by Paul Lautman | last post: by
7 posts views Thread by Steven Woody | last post: by
5 posts views Thread by yogeshmk | last post: by
reply views Thread by bestbikeever | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.