[omniORB] string_dup() behavior

[baileyk@schneider.com]

> The string allocation functions are inline for speed. The only
> platform we've ever encountered that has a non-uniform memory
> architecture is Windows. I believe (although I might be wrong) that
> there are other very good reasons that debug/threading etc. modes must
> be matched between all application code and DLLs on Windows. If this
> really is the case, it's a good thing to keep the string allocators
> inline, since it causes pretty much all Windows programs to break very
> quickly if they have the wrong settings. The other issues are probably
> more sneaky.

Don't take my word, I'm not a Windows guru.  I _have_ been force to mix
vendor supplied libs which didn't share a common runtime dependency and it
always worked unless memory allocations were allocated in one and deleted
by the other.

Perhaps I'm wrong and the CORBA allocation functions are not a work-around
for Windows, but rather a hook to allow an ORB vendor to supply a better
allocator than stock malloc/new?  In any case, I don't know that omniORB
should play runtime cop and fall over when a mismatch is detected.  A
Windows developer should complain to Microsoft if the linker is so sneaky!
Let MS fix the tools to make it easier to get things right.

Also, as has been pointed out, strings are not the only things allocated
which the ORB must release.  An ORB must have a global policy of providing
the memory allocations for all strings, structs, etc. or not.  Does the IDL
compiler arrange for overriding operator new() and delete() in structs or
is there another trick to get "new myStruct" to use the ORB's allocator?

btw, Is the speedup dramatic?  I would think a malloc() would swamp the
overhead of one more function call.

Kendall