|
http://osdir.com/ml/lib.icu.general/2003-05/msg00032.html Hi, I have a C++ framework (http://vcf.sf.net) I have been working on. I have gotten a fair amount of interest from developers in other countries (quite a few from Brazil, for whatever reason), and have frequently been asked about i18n and l10n support. At this point there is no support for it in the framework proper (other than a largely empty, and non-functional, Locales class). However I would appreciate peoples advice/thoughts/comments on how approach adding support for in my library. My thinking at the momement is this: it seems to me I can add this support in 1 of 3 ways 1) use the IOStream and the std::facet and std::locale classes pros: part of the standard C++ Lib, and thus fits with everything else (sort of) cons: kind of wanky to understand, not widely used (or understood either, from what I can tell), and it appears that the implementation of it varies widely on the STL implementations. For example in the VC6 version of STL you have to use weird macros to deal with the facet classes (instead of having implemented has_facet() they have you use a macro _HAS). In STLPort I read in one of the forums that there were bugs in the implementation of some of the classes (don't remember which at the time) that make using it kind of iffy. 2) use ICU which seem VERY feature complete pros: has alot of features, and seems generally to have been quite well thought out. Supports everything it would seem you'd want or need in this sort of library. cons: It's huge, and hard to "break" apart (at least AFAIK, I readily admite I may be wrong here), plus it has a number of duplicate features in it that my framework already provides support (i.e. threads, file io, etc). For example, it has it's own thread support package. Also not entirely sure how to integrate it 3) Use a peer approach. Define an interface ( or series of interfaces) that encapsulate the functionality that is needed, then implement each for the platform being ported to, as most of the major platforms seem to have support for this built in. For example, Windows (Win32), MacOSX, and Linux all have support for message catalogs, as well as varying degrees of Unicode conversion (Win32 and MacOSX are complete in this aspect, with Linux so-so, AFAIK), and also have support for stuff like collating, etc. pros : takes advantage of the native platform, where it makes sense. A default implementation could even make use of the ICU library mentioned above, simply forwarding the various calls along to it. This also makes it "easier" in terms of integration into my framework. cons: ??? not sure there's any? At the momement I am leaning towards option 3. If I do this it seems to me that the major things I need to provide support for are: translating strings from ascii to Unicode (and vice-versa), and allowing this to work with different code pages have a standard string class that is Unicode based (in terms of it's internal data) and have a super set of functionality of the std::basic_string<> class. I want the compatibility with basic_string<> because the framework uses STL heavily and I don't want to have to rewrite a bunch of code for no good reason. allow for conversion to and from a number of different formats, such as numerical data, currency, time, dates, etc, to a string value (that is internally Unicode) allow for collation of strings (i.e. comparing string A is less than, great than, or equal to string B) meesage catalogs, the ability to request an identifier for a string be matched to a localized string value consistent with the current locale for the program identify and setting the current locale of the program, on at least a process level, and perhaps by thread. Am I missing anything here? Does anyone have any experience with this? Any comments or suggestions, particularly if you have used ICU for your own apps. Thanks Jim Crafton |
