Collation implementation

[Martin v. Loewis]

> Function names in the C library subset of Std C++ ARE different from the
> names in the real C library. 

>From a standards point of view, there is no guarantee they are the
same. From a real-life point of view, they should be, and typically
are, the same.

> They are all std::function_name() and most macros are also inline
> functions.

Well, the typically have extern "C" linkage, so the link with the
global functions even if they are scoped with std::.

If the C functions and the C++ functions are different, you have
severe problems combining a C library into a C++ program. For example,
if malloc(3C) was different from std::malloc, then allocating memory
with malloc and releasing it with std::free would not work - although
users reasonably can expect that to work.

> 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.

It's not that much the functions that may conflict, but the structures
passed as parameters.

> 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.

It the moment, I have no concrete plans to contribute any specific
code to libstdc++ v3 (except for bug fixes as I may find bugs); so it
is not really my job to consider or not consider ICU for anything -
I'm rather looking at it from a user's point of view.

> 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.

You don't have to convince me; nor would I want to convince you - I'm
responding to this message just as I still see misconceptions on the
general C/C++ combination issue - on ICU itself, I think our mutual
views are clear.

No offense intended,

Martin