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

From: Eddie Diener (eddielee_at_[hidden])
Date: 2004-07-05 18:21:06

Vladimir Prus wrote:
> Edward Diener wrote:
>
>>> I had in mind situation where there are two applications -- one
>>> which uses narrow version and another which uses wide version. If
>>> each library is used by several apps -- which is likely, and not
>>> all those apps agree and narrow/wide question, you really need to
>>> install two versions for each library.
>>
>> I don't understand what you are saying in the penultimate clause
>> "and not all those apps agree and narrow/wide question". If an
>> application uses both the narrow and wide versions of a library,
>> then of course it will have to include both of them. My own
>> experience is that most applications will use one or the other.
>
> Probably we misunderstand each other because I have in mind Linux
> model of application installation. Each application and each library
> is a separate package. Typically, a library is used by several
> applications.

That's normal.

>
> Now, I have a number of library packages. Say no application uses
> wide char interface at the moment, so only narrow libraries are
> installed, Now, a single application decides to use wide interface,
> so its package now depends on wide libraries. As the result, I have
> to install, in addition to some narrow libraries, their wide
> equivalents.

You only have to install the appropriate wide equivalents. There is nothing
to say that a wide character application uses all wide character libraries.
Obviously whatever wide character implementations it uses should be a
package which can be installed as part of the application distribution.

> After enough applications decide to use Unicode, most
> libraries will have to be installed in two flavours.

How is this worse than having a single version which has both wide and
narrow character equivalents ? You are not saving anything in this latter
way, and you are definitely worse than if the libraries were separate and
you only used one or the other versions in your applications.

>
>> I think C++ should have template specializations for all of its
>> native character types in its standard libraries whenever a
>> character is being used properly as a native character type type.
>> Currently C++ has two native character types, 'char' and wchar_t'.
>> In the future who knows whether ot not other native character types
>> will be added, perhaps a specific Unicode type. Using templates, and
>> having specializations of its native character types, makes it much
>> easier for C++ to adapt other future character types as native
>> character types.
>
> I don't think this is very likely for new character types to appear.

I do. I would be very surprised if C++ does not adapt new character types in
the years to come. Do you really think that if the programming world settles
on other standard character representations that C++ will adamantly ignore
it ? Even now a number of programmers would like to see C++ support one of
the Unicode standards natively, most likely UTF-32.

>
>> Even when other native
>> character types are not added to C++, creating one's own
>> implementations of character types is much easier when templates and
>> specializations are used. We have this wonderful facility in the C++
>> language, templates. Not using it, because an application might have
>> to use different character types and include more than one
>> specialization, seems illogical to me.
>
> I'm actually worried that when using templates in a straight-forward
> way, all libraries will have to some in two variants or be twice
> larger, which is bad because of:

No. There is nothing saying that a library must support more than one
character type. But if it does, isolating each character type in its own
header files and libraries is the right design.

> - code size reasons,
> - configurations reason (just one more configuration variant to worry
> about)
> - interoperability/convenience? (what if I use unicode paths and want
>   to pass narrow string to one of the operators?)

None of your reasons holds much weight. Code size wouldn't be affected since
each implementation is in its own library. There is nothing to configure
since character types are part of the C++ standard. If you need to pass a
unicode path to a narrow string operator, you the programmer are either
doing something wrong or, if there is a valid conersion, you can make it
yourself ( like wcstombs ).

>
> 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.
Why make headaches for oneself ? I am always in favor of designs which are
clear and understandable over all other considerations. The headaches one
brings about in the future by trying to save a little size of speed in the
present are innumerable. If there is a conversion between character types, I
don't mind if a library for a particular character type supports it. When I
say different libraries for different character types it doesn't preclude
conversion routines.