[Boost-users] Re: Feature request for boost::filesystem

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-02 02:48:12

David Abrahams wrote:

>>>> 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.
>>> 
>>> It doesn't have to be.  There can be a library object with explicit
>>> instantiations of the wide and narrow classes.
>>
>> Which doubles the size of shared library itself.
> 
> It depends; the narrow specialization might be implemented in terms
> of the wide one ;-)

Yes, and that would be absolutely reasonable. 

I think I'm not 100% against templated classes, I'd only want that:
1. wide version and narrow version is freely convertible to each other
2. there's only one price to pay: if you use either version you need to link
one library which is 100K or 100M in size. If you use two versions you
don't have any additional costs.

In this way each library can use whatever interface is more *convenient*,
but it will still be unicode aware.

For example, the design for boost::path that I have in mind is:

class path {
   std::string native_file_string();
   std::string native_file_wstring();
};

the templated interface might be:
template<class charT>
class path {
   std::basic_string<charT> native_file_string();
};

It's in fact move convenient, because if you work only with wide string, you
save one character when converting path to string. I don't know if this
convenience justifies asking the user which kind of path he wants. Maybe it
does. But if my two requirements above are met, it's only a convenience
matter.

BTW, probably single path can be move convenient in other situations:

   p = p / L"foo" / "bar";

- Volodya