Boost logo

Boost Users :

From: Keith MacDonald (boost_at_[hidden])
Date: 2004-07-01 09:10:49

I can't see why this has to be so complicated. I either build my Windows
apps for DBCS or for Unicode, so use the narrow or wide Win32 file system
API accordingly. All that I want from boost::filesystem is a simple switch
that sets its mode at compile time. Doing that with a template parameter is
not going to cause any code bloat, and is neater than Microsoft's #ifdef
_UNICODE method.

I suppose some people may want to use narrow and wide APIs within a single
application, but they can't use boost::filesystem now anyway, so just keep
it simple.

- Keith MacDonald

"Vladimir Prus" <ghost_at_[hidden]> wrote in message
> Delfin Rillustration> So what I ask is a library that works everywhere,
> like you say.
> >
> > I understand your point about POSIX file systems but since the library
> > compiled for Windows _or_ for POSIX systems I think it would be possible
> > to compile for single char strings or double byte strings (UTF16).
> > systems solve this problem with the concept of TCHAR, a type that is
> > defined as a char or wchar_t depending on a preprocessor definition.
> > boost::fylesystem::path could accept std::basic_string<TCHAR> instead of
> > std::basic_string<char>. That would solve the problem and everybody
> > be happy ;)
> I'm very much opposed to the idea of having templated classes for unicode
> support.
> Let me explain. Suppose I write a library which does something with
> paths, whatever in the interface. I have these choices:
> 1. Make the library interface templated.
> 2. Use narrow classes: e.g. string
> 3. Use wide classes: e.g. wstring
> 4. Have some class which works with ascii and unicode.
> The first approach is bad for code size reasons. If the library does
> substantial work (e.g. HTTP library), it better be dynamic library, so
> applications don't have include all the code. Of course, you might want
> static linking, but dynamic linking should be possible too.
> The second approach is what's commonly done. As the result, unicode is not
> very supported in the standard C++.
> The third approach looks reasonable. However, Mr. Random Library Writer
> might think: "I don't have a need for unicode now, so wstring is
> So he might discard this approach and use std::string.
> Even if wstring is used, there are some issues. E.g. std::wstring does not
> have a constructor taking either char* or std:string, or if you ever get
> ascii string, you're in trouble.
> The last solution is what looks most reasonable to me. It would be nice to
> have unicode string which can be created from ascii or unicode, converted
> back to either representation, and manipulated without regard to encoding.
> For fs::path it would be that unicode will be just supported. The
> solution will bring us back to the above choice. And if you have a library
> which has boost::filesystem::basic_path<char> in the interface, it does
> matter if your whole application uses basic_path<charT> -- you'd need
> conversions somewhere, so why don't have single fs::path which can do all
> conversions.
> Just an illustraction:
> class path
> {
> path(const std::string& s); // The 's' is in the local 8-bit encoding
> path(const std::wstring& s); // The 's' in in unicode
> template<class charT>
> std::basic_string<charT> native_file_path();
> // other operations, independed of charT
> };
> - Volodya

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at