
On Sun, Mar 6, 2011 at 6:32 AM, Yechezkel Mett <ymett.on.boost@gmail.com> wrote:
On Thu, Mar 3, 2011 at 8:29 PM, Beman Dawes <bdawes@acm.org> wrote: ...
"The default imbued locale provides a codecvt facet that invokes Windows MultiByteToWideChar or WideCharToMultiByte API's with a codepage of CP_THREAD_ACP if Windows AreFileApisANSI()is true, otherwise codepage CP_OEMCP. [Rationale: this is the current behavior of C and C++ programs that perform file operations using narrow character string to identify paths. Changing this in the Filesystem library would be too surprising, particularly where user input is involved. -- end rationale]"
It should use CP_ACP not CP_THREAD_ACP, because that's what the Windows API functions (CreateFile etc) and the C library functions (fopen etc) use. The C++ library functions (fstream::open etc) do in fact use the C global locale (by way of mbstowcs if I remember correctly).
(CP_THREAD_ACP should never be used for converting code pages - it's based on the User Locale which is for sort orders and numeric formats.)
Hum... I marked your previous message http://lists.boost.org/Archives/boost/2010/11/173382.php for action, and then never did anything about it. Sorry, my mistake. It would be very confusing and error prone if std::fstream, boost::filesystem::fstream, and boost::filesystem operational functions treat a narrow string filename differently. Since std::fstream can't be changed, that implies whatever a given standard library does should be what boost filesystem does. That further implies that if library A does it one way, and library B does it a different way, boost filesystem should do it the way standard library version does it, even if that means a program using filesystem compiled with VC++ could behave differently than if compiled with some other compiler. Does that make sense? So a test case is needed that will distinguish between the C++ standard library fstream using CP_ACP, C global locale, or something totally different. Do you already have such test code or could you put something together? Thanks, --Beman