[Development] ICU and Windows

[Sascha Cunz]

[...]

> Microsoft in the past has also said that you should keep the -MD(d)/-MT(d)
> setting consistent so it is the same across all libraries and applications,

[...]

Which is cool, if you can manage it. But it's far from what happens in the 
real world.

In the real world you have foreign libraries to load, doesn't matter if these 
are stock libraries provided from Microsoft, from 3rd parties or even 
yourself. It is not uncommon to have all kinds of memory managers mixed in one 
application (some windows libraries still use MSVC6's runtime as dll).

However - like Thiago said - as long as you keep on freeing your memory 
yourself and never another library's HEAP-memory, everything's fine.

Heap memory here clearly refers to memory allocated by calloc, malloc or 
::operator new() as opposed to memory allocated via HeapAlloc, VirtualAlloc or 
any COM-Mechanism, which are designed to be shared depending on settings.

Actually, this means: You can mix C/C++ freely. At least in the Microsoft 
universe, operator new() is just a wrapper for malloc or it's debug counter-
part.

Contrary to Thaigo, I had assumed that the C++ case is in general more 
problematic. I don't know for the icu-case at hand, but generally C-libraries 
tend to provide a free method, like FOOLibrary_free(void*) for free'ing 
memmory allocated by them.

For C++, consider this:

In library 1:
	struct A{ virtual ~A(); };

	void x( A* a ){ delete a; }

In library 2:
	struct B : A { ~B(); };

	void y(){ x( new B ); }

Whose memmory manager's free() will be used if those 2 libraries link against 
different memory managers?

Sascha