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.