[omniORB] string_dup() behavior

[baileyk@schneider.com]

>> I will try to remove the inline as soon as I get a chance.
> Don't go down that path.

Unless I don't know what I'm talking about, it should solve the specific
problem with CORBA::string_dup().  Can someone explain why non-inlined
memory allocation functions are a bad idea?  Will it hurt performance that
much?  My reading of things is that the CORBA spec was designed to allow
the ORB to manage _all_ of the memory allocations that it may need to
deallocate (through the CORBA::string_* functions and overloaded operator
new() and operator delete() members in structs/classes).  omniORB is not
broken if it doesn't take advantage of this possibility, but it's not as
flexible as it could be for Windows users.  AFAIK it is not an illegal to
mix runtimes in one process.

>> Can I resolve the problem another way by compiling and
>> linking my executable with the same runtime
>> used by the omni DLL? Wouldn't that be as simple as building
>> them with the same compiler options?
> Yes.  Use /MD in your project as stated earlier.  In Visual Studio 6 it
is
> Project Settings/C++/Code Generation/Use runtime library: Multithreaded
DLL

This is the best way to go, for sure.

Kendall