id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
6065,Accessing Windows paths with non-ANSI characters fails with g++,alf.p.steinbach@…,Beman Dawes,"For example, the tut5 example in Boost.Filesystem's tutorial does not work with g++ 4.4.1 (it fails to create the filenames with smileys), but that example does work with Visual C++ 10.0.

""ANSI"" here refers to the process' ""ANSI codepage"".

By default in a US or Western European Windows installation that's codepage 1252, Windows ANSI Western.

Cause: Boost.Filesystem uses extensions in the Dinkumware standard library implementation to provide general Unicode access to paths in Windows.  g++'s standard library lacks those extension as of version 4.4.1 (and probably up to and including the latest version). Extending the g++ standard library in a similar way as Dinkumware was discussed in June 2011, <url: http://gcc.gnu.org/ml/libstdc++/2011-06/msg00066.html>, but as far as I know nothing more came of that.

Boost.Filesystem v2 worked around the g++ implementation by using Windows short filenames and the Windows API-funcion CreateFile for creation of files. One problem is that the user IN PRINCIPLE can turn off generation of short filenames as a marginal optimization. However, Windows uses short filenames in the registry, reportedly MSI (the Microsoft Installer) uses short filenames, etc., so it's a very unlikely scenario. In the unlikely event that a user does turn off short names, then programs using the v2 workaround will fail in the same way as if they didn't have the workaround, i.e. as currently.
",Bugs,new,To Be Determined,filesystem,Boost 1.47.0,Problem,,"windows, paths, unicode",