Boost C++ Libraries: Ticket #6065: Accessing Windows paths with non-ANSI characters fails with g++ https://svn.boost.org/trac10/ticket/6065 <p> 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. </p> <p> "ANSI" here refers to the process' "ANSI codepage". </p> <p> By default in a US or Western European Windows installation that's codepage 1252, Windows ANSI Western. </p> <p> 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, &lt;url: http://gcc.gnu.org/ml/libstdc++/2011-06/msg00066.html&gt;, but as far as I know nothing more came of that. </p> <p> Boost.Filesystem v2 worked around the g++ implementation by using Windows short filenames and the Windows API-funcion <a class="missing wiki">CreateFile</a> 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. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/6065 Trac 1.4.3