[filesystem] introduce wide-only mode?
Hi, while porting Boost to evc4 I noticed that Boost.Filesystem makes heavy use of the Ansi Win32-API functions such as CreateFileA etc. There is a mode that can be enabled with the define BOOST_FILESYSTEM_NARROW_ONLY so that only Ansi APIs are used. Is it thinkable to introduce a BOOST_FILESYSTEM_WIDE_ONLY mode, e.g. when BOOST_NO_ANSI_APIS is defined? Should I try to implement such a mode, or is it too complicated? bye Michael
"Michael Fink" <michael.fink@asamnet.de> wrote in message news:26659.217.6.216.4.1146833083.squirrel@www.asamnet.de...
Hi,
while porting Boost to evc4 I noticed that Boost.Filesystem makes heavy use of the Ansi Win32-API functions such as CreateFileA etc. There is a mode that can be enabled with the define BOOST_FILESYSTEM_NARROW_ONLY so that only Ansi APIs are used. Is it thinkable to introduce a BOOST_FILESYSTEM_WIDE_ONLY mode, e.g. when BOOST_NO_ANSI_APIS is defined? Should I try to implement such a mode, or is it too complicated?
What would the motivation be? BOOST_FILESYSTEM_NARROW_ONLY is a workaround for libraries and/or compilers that don't support wide characters or enable if. I really don't like it - the code would be clearer without it. I hate to add yet another workaround unless there is strong motivation. --Beman
Beman Dawes wrote:
What would the motivation be?
BOOST_FILESYSTEM_NARROW_ONLY is a workaround for libraries and/or compilers that don't support wide characters or enable if. I really don't like it - the code would be clearer without it. I hate to add yet another workaround unless there is strong motivation.
Windows CE and its siblings don't provide narrow-character versions of most API functions. That would be the motivation to have a version that doesn't use them. Sebastian Redl
Beman Dawes wrote:
"Michael Fink" <michael.fink@asamnet.de> wrote in message news:26659.217.6.216.4.1146833083.squirrel@www.asamnet.de...
Hi,
while porting Boost to evc4 I noticed that Boost.Filesystem makes heavy use of the Ansi Win32-API functions such as CreateFileA etc. There is a mode that can be enabled with the define BOOST_FILESYSTEM_NARROW_ONLY so that only Ansi APIs are used. Is it thinkable to introduce a BOOST_FILESYSTEM_WIDE_ONLY mode, e.g. when BOOST_NO_ANSI_APIS is defined? Should I try to implement such a mode, or is it too complicated?
What would the motivation be?
On WinCE there are only wide character file names, you'll get linker errors if the narrow character stuff is included. John.
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:00f801c674db$45280bb0$5c441b56@fuji...
Beman Dawes wrote:
"Michael Fink" <michael.fink@asamnet.de> wrote in message news:26659.217.6.216.4.1146833083.squirrel@www.asamnet.de...
Hi,
while porting Boost to evc4 I noticed that Boost.Filesystem makes heavy use of the Ansi Win32-API functions such as CreateFileA etc. There is a mode that can be enabled with the define BOOST_FILESYSTEM_NARROW_ONLY so that only Ansi APIs are used. Is it thinkable to introduce a BOOST_FILESYSTEM_WIDE_ONLY mode, e.g. when BOOST_NO_ANSI_APIS is defined? Should I try to implement such a mode, or is it too complicated?
What would the motivation be?
On WinCE there are only wide character file names, you'll get linker errors if the narrow character stuff is included.
For WinCE, what is needed isn't to disable narrow paths, but to alter the implementation so that narrow paths get converted internally to wide paths. In other words, the reverse of the POSIX implementation, which converts wide paths to narrow. There are several aspects of such an enhancement: * The change to the implementation itself. * Figuring out test cases and updating the regression tests. * Finding one or more volunteers to run Boost regression tests for the WinCE platform. Are there Boosters out there who care enough about Windows CE to take this on? --Beman
John Maddock <john@johnmaddock.co.uk> wrote:
while porting Boost to evc4 I noticed that Boost.Filesystem makes heavy use of the Ansi Win32-API functions such as CreateFileA etc. There is a mode that can be enabled with the define BOOST_FILESYSTEM_NARROW_ONLY so that only Ansi APIs are used. Is it thinkable to introduce a BOOST_FILESYSTEM_WIDE_ONLY mode, e.g. when BOOST_NO_ANSI_APIS is defined? Should I try to implement such a mode, or is it too complicated?
What would the motivation be?
On WinCE there are only wide character file names, you'll get linker errors if the narrow character stuff is included.
I could use that too, on "normal" Windows programs compiled under current verions of VC++ ; just like I avoid std::string and use std::wstring instead. There are two problems with *A functions: - (minor) performance cost of conversions, as all strings have to be converted to and from Unicode (*A variants are just wrappers for *W variants) - these conversions are controlled only by user/computer regional settings, which means that behaviour of program using them will vary depending on where it's run, if it happens to operate on names containing non-ASCII characters. B.
participants (5)
-
Beman Dawes -
Bronek Kozicki -
John Maddock -
Michael Fink -
Sebastian Redl