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.