I think you bring very good points. When you receive a path object back from a directory iteration and you want to convert it to string it is really dangerous to expose both narrow and wide strings because the caller doesn't know if the string had a good conversion or not. On the other hand, I don't agree these arguments say the narrow vs wide decision cannot be made at compile time. If the programmer compiles the library for single character strings then she/he knows what to expect. After all a project in Windows gets compiled for single char or double char strings. Boost::filesystem can talk to several filesystems from within a single program but it currently has only two implementations; one implementation for POSIX and one for Windows. On Windows OS all the calls to any file system will happen through the Windows API which takes narrow and wide strings. In the POSIX system there is no wide string support for the file system so the library should work with narrow strings internally. -delfin -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Tuesday, July 06, 2004 3:35 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Re: Re: Feature request for boost::filesystem Eddie Diener wrote:
Vladimir Prus wrote:
With a bit of additional design, it's possible to make library use one representation internally, and have either non-templated interface, or a tiny templated facade. E.g:
boost::path p; p = p / L"foo" / "bar";
does not seem all that bad thing for me.
It is possible to do that if you can convert all character types into your internal representation. Even here I am paying for conversionsa back and forth I may not need. I therefore would prefer separate templated libraries.
I'm not sure which conversions back and forth you have in mind, and how separate templated libraries avoid them. The goal of Boost.Filesystem is to allow you to write OS-independent code. However the native path character is OS-dependent. So if you, for example, enumerate a directory, you will get back paths that are either narrow or wide, depending on the native character type. You cannot make the narrow vs wide decision at compile time (assuming that the code does not change), because (1) there are wide paths that do not have a narrow representation, and vice versa; (2) Boost.Filesystem can talk to several different filesystems from within a single program. It is possible to typedef basic_path<_Native_fs_char> path, but then p /= "images"; may fail - you'll need to use BOOST_FS_PATH("images") or something equally ugly. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users