1

What is the relation between following standard C++ functions and locale

std::fopen, std::fstream::open

Till now whenever i used these standard functions , i never thought anything about locale so why should i ever be bothered about locale?

While reading through stackoverflow i came across this

Everything usually works fine on Linux as everyone uses UTF-8 based locales so all user input and arguments passed to main functions will be UTF-8 encoded. But you might still need to switch current locales to UTF-8 variants explicitly as by default C++ program starts using default "C" locale.*

What is the above paragraph trying to say exactly? What is wrong in windows and OK in linux as per above paragraph?

Can anyone please explain in simple words preferably with a example?

Test
  • 564
  • 3
  • 12
  • 2
    "why should i ever be bothered about locale?" - because your code will (hopefully and eventually) get to run on many different types of computers operated in different parts of the world with very different assumptions about how textual data is formatted. – Dai Jan 10 '22 at 04:40
  • 1
    You cited "UTF-8 based locales" as your excuse for keeping your head buried in the sand - but you are mistaken: there's **considerably more** aspects to locales than just text encoding - think about things like writing direction, currency symbols, [sane vs. insane date/time formats](https://xkcd.com/1179/), 12 vs. 24 hour clocks, or even if `\n` by itself is a valid line-break (on Win32 it's `\r\n`, and on ye olde MacOS it's `\r` without an `\n`) – Dai Jan 10 '22 at 04:42
  • @Dai - whereas i understand what is locale is for but my query is more about getting clarity with bit more detail from the point of view standard c++ functions and locale. Can you cite few use cases explaining the scenario? – Test Jan 10 '22 at 04:42
  • "my query is more about getting clarity with bit more detail from the point of view standard c++ functions" - so I assume you've read your toolchain's documentation for `std::locale` then? The `man` pages for it covers a lot of ground, so it would help us if you could cite part of your C++ docs that you have a question about instead of an uncited StackOverflow post. – Dai Jan 10 '22 at 04:45
  • The SO post that I had to cite for you concerns data-types used to represent textual characters (i.e. `char` vs `wchar_t`) and while the answer does mention C++'s `std::locale` -they're only using it as a proxy for C and C++'s built-in support for different character sets/text encoding schemes, which is a very small part of what the larger `std::locale` library is all about. – Dai Jan 10 '22 at 04:49
  • @Dai - I read https://www.cplusplus.com/reference/cstdio/fopen/ and didn't see anything which should take me towards locale. So my initial question is about relating standard c++ functions and locale and how to achieve whats right way to do things. – Test Jan 10 '22 at 04:59
  • (Kinda off-topic, but you shouldn't be using `fopen` if you're writing idiomatic C++) – Dai Jan 10 '22 at 05:03
  • 1
    The C standard does not consider `fopen` to depend on the current locale. It does have this to say though: "Functions that open ... files require a *file name*, which is a string. The rules for composing valid file names are implementation-defined." So then you need to consult implementation details. (continued) – Igor Tandetnik Jan 10 '22 at 05:34
  • 1
    It is my understanding that on Linux, the string you pass to `fopen` is passed along to the file system as-is, and most file systems nowadays use UTF-8 to represent file names. On Windows, the file system uses UTF-16, while `fopen` assumes the string to be in system default codepage (aka `CP_ACP`). It is possible to create a file with a name using characters not representable in `CP_ACP`, and that cannot be named in `fopen`. The standard library shipped with MSVC compiler provides `_wfopen` function, which works like `fopen` but takes `wchar_t*`, whereby you supply the file name in UTF-16. – Igor Tandetnik Jan 10 '22 at 05:38

0 Answers0