Markus Scherer wrote:
> Hi Dave,
> On Wed, Feb 25, 2009 at 2:55 PM, David Bertoni <dbertoni@...
> <mailto:dbertoni@...>> wrote:
> This would only happen if the ICU DLL and the application calling the
> ICU API are compiled with a different C run-time library. Mixing
> run-times is explicitly disallowed by Microsoft:
> If my memory serves me right, we had user issues years ago that turned
> out to be the application and ICU using different runtimes (allocators).
> I believe it was impossible to guarantee that they match, unless they
> are compiled together, so I think we deliberately chose different
> runtimes for the test suites than for the libraries, to catch these
> things in our own testing. (This might be the case only on
> Windows.) This is also when we introduced the UMemory base class with
> its new and delete operators, which make sure that the ICU library's own
> allocator is used when deleting an ICU object.
The way to guarantee the run-times match is to make it a requirement
that clients use the DLL run-times when linking with DLLs. I'm sure
there are many other commercial and open-source products out there that
enforce this requirement. For example. Xerces-C and Xalan-C have always
required matching run-times.
I don't think this is any different than how GCC works, since its C
run-times are provided as static archives and shared objects. I believe
GCC's C++ run-time is _only_ provided as a shared object.
The ICU's memory hooks only work transparently with C++ objects and
new/delete. For C code, the ICU would need to provide some sort of
> We probably want to keep it that way.
Well, Microsoft explicitly says "don't do that," which seems reason
enough to stop supporting such configurations.
> Please let me know if I am misremembering, or if you think we can start
> requiring a consistent runtime.
> (Currently, intltest uses /MTd while the common library uses /MDd.)
> Check the run-time library option on the code generation tab in the
> project settings. There is no way to use std::string in the APIs if the
> run-times are not consistent.
> You cannot engineer this in any way that it will work on Windows using
> Just a lovely language with a lovely standard library implemented in
> lovely ways. This kind of stuff makes me wish I spent my days writing
> Java or Python code.
Well, the way to make this work would be to get rid of the static
run-time libraries completely, which is the direction Microsoft is
headed in, if you look at the history of the available run-times for
successive versions of the compiler. And GCC seems to have chosen that
path from the beginning.
> To make this work on Windows, you would need to write
> your own Allocator class that uses the ICUs allocation functions, and
> use an instantion of the basic_string template that uses your allocator
> class. The resulting class will not be type-compatible with
> Fix the run-time and require consistent run-times,
> I think we can't, see above.
> or implement an
> ICU-specific specialization of basic_string. I can help with the later,
> if you think that's worthwhile, but without compatibility with
> std::string, I'm not sure how useful it is.
> I am not sure either. I will try to think of alternatives.
It might be possible to make this happen automatically by providing a
conversion operator from std::basic_string<char, char_traits<char>,
ICUAllocator> to std::string.