Howard said:
version
You'd be much better off looking on the microsoft news server
(news.microsoft.com) for a newsgroup that can address this issue. This is
VERY Microsoft-specific stuff! (For one thing, we haven't the faintest idea
what that problem or solution was that you mention, so we've no way to
comment on how it might or might not help you.)
I don't see it this as a MS speciffic issue. It's a common hassle when
exchanging objects across "build" bounderies. Under Windowze, this is
typically between an exe and a dll or between dlls. On an another os this
may involve shared libraries instead.
Whatever, lets call it an Execution Unit (EU) for the sake of the argument.
Every EU will tend to have its own copy of the runtime libraries and c++
memory manager statically linked in and this is the core of the issue. You
get multiple housekeepings.
If you create a std::string in one of these and pass it on for manupulation
across EU, the chances are it'll get damaged. There is no way one typical
c++ memory manager can free a block allocated by another memory manager even
though both run in the same address space, unless, they'd be allocating
everything on the system heap in which case there would be no need for them
at all. Expect your app to slow down considerably though in that case.
Windows has system wide object like _bstr_t (yes, ms specific) to allow for
the safe exchange of strings across EUs.
In general, the trick is to make sure that within one application's process
space, only one central memory manager is used. You can do that by
implementing your own new and delete and malloc and free variants and
exposing these from a singular EU that every other EU must link to or you
could for example use a commercial product like SmartHeap to do this for you
(available on several platforms). A specific class exposed from one EU can
also deal with this by overloading operator new, delete, new[], delete[] and
their throw (nothrow) variants. MFC does this a.f.a.i.k in CObject. This
forces an mfc instance to get newed and deleted from inside the mfc dll.
On a larger system with many EUs, frankly, my advise is to go for a thing
like SmartHeap (you get a lot more than merely centralized memory manager).
It pays in the long run.
h.t.h. somewhat
Conrad Weyns.