RE: Collation implementation

["Shiv Shankar Ramakrishnan" <Shiv at pspl dot co dot in>]

|Well, there is a way: Just use ICU in your application, instead of the
|standard C++ classes. Namespaces and other mechanism in C++ make it
|easy for programmers to combine different libraries.

Thanks. That I already do. Thats not the point. We are trying to make
the C++ locale facility more usefull. Users should not always have to
ship or support ICU with libsdtc++ on their own. Whats the fun in a
*Standard* C++ locale facility if its not usefull to all?
|a single operating system process, for structure layouts and function
|names would conflict.

Function names in the C library subset of Std C++ ARE different from the
names in the real C library. They are all std::function_name() and most
macros are also inline functions. I don't see how they would conflict
except for very few names that are still macros in the C subset of the
Std C++ library.

|I thought the conclusion was that it is feasible to integrate a C
|library with the C++ library. It is not.

I would like the C++ library designers to comment upon this.

|to setlocale these days. But perhaps you have no GNU programs around
|you...

Nice try ... And what am I doing on the libstdc++ list?

|Ok, I have repeatedly listed a number of problems I see. Let me put it
|differently: Just try to integrate ICU, and see what kinds of problems
|users report afterwards.

You seemed to mention only a couple of problems. I didn't see the so
many number of problems you mention. Moreover you don't even want to
think about trying to work around them or some amicable solution.

I think you are plain hostile to even allowing the possibility of using
ICU locale data for C++ (read not C) locales at user choice (read non-
default). I don't think I can explain any more or argue any more. I give
up. Somebody else try if you want to. Maybe Nathan can try. I am NOT
going to argue with you anymore on this.
Thanks,
Shiv