BUG: Wrong Operator Delete Called for Exported

[Dmitri Zhukov]

This topic was widely discussed before but somehow I still have no idea how
to fix the problem.

I've a C++ class which resides inside DLL and has some STL members inside.
The EXE uses STL vector of my classes and get run time crash on the
destructors in the RTLValidateHeap function.
The knowledge base Q122675 article explains the situation. However the
solution offered by Microsoft on declaring constructor and destructor inline
does not work. I have the problem on Intel Compiler and STLPort's version of
STL.

Best Regards,
Dmitri Zhukov.

[Howard]

"Dmitri Zhukov" <di*******@mail.ru> wrote in message
news:be**********@alpha2.radio-msu.net...

This topic was widely discussed before but somehow I still have no idea how to fix the problem.

I've a C++ class which resides inside DLL and has some STL members inside.
The EXE uses STL vector of my classes and get run time crash on the
destructors in the RTLValidateHeap function.
The knowledge base Q122675 article explains the situation. However the
solution offered by Microsoft on declaring constructor and destructor inline does not work. I have the problem on Intel Compiler and STLPort's version of STL.

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.)

-Howard

[Conrad Weyns]

"Howard" <al*****@hotmail.com> wrote in message
news:be********@dispatch.concentric.net...

"Dmitri Zhukov" <di*******@mail.ru> wrote in message
news:be**********@alpha2.radio-msu.net...

This topic was widely discussed before but somehow I still have no idea how

to fix the problem.

I've a C++ class which resides inside DLL and has some STL members inside. The EXE uses STL vector of my classes and get run time crash on the
destructors in the RTLValidateHeap function.
The knowledge base Q122675 article explains the situation. However the
solution offered by Microsoft on declaring constructor and destructor

inline

does not work. I have the problem on Intel Compiler and STLPort's

version of

STL.
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.

-Howard

[Howard]

"Conrad Weyns" <we***@online.no> wrote in message
news:mQ*******************@news4.e.nsc.no...

"Howard" <al*****@hotmail.com> wrote in message
news:be********@dispatch.concentric.net...

"Dmitri Zhukov" <di*******@mail.ru> wrote in message
news:be**********@alpha2.radio-msu.net...

This topic was widely discussed before but somehow I still have no

idea

how

to fix the problem.

I've a C++ class which resides inside DLL and has some STL members inside. The EXE uses STL vector of my classes and get run time crash on the
destructors in the RTLValidateHeap function.
The knowledge base Q122675 article explains the situation. However the
solution offered by Microsoft on declaring constructor and destructor

inline

does not work. I have the problem on Intel Compiler and STLPort's

version

of

STL.

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.

Well, since he's talking about a Microsoft knowledge base article that deals
with a DLL, running under Windows, and since we have no idea what that
article describes as the problem or solution, wouldn't you think that their
newsgroups might be a better source of info on how to fix this particular
problem than a newsgroup devoted to the C++ language?

(And a little more info than what was provided would also be
helpful...nobody should have to go hunting for a MS knowledge-base article
just to answer somebody else's question.)

-Howard

[Jack Klein]

On Thu, 3 Jul 2003 22:58:31 +0200, "Conrad Weyns" <we***@online.no>
wrote in comp.lang.c++:

"Howard" <al*****@hotmail.com> wrote in message
news:be********@dispatch.concentric.net...

"Dmitri Zhukov" <di*******@mail.ru> wrote in message
news:be**********@alpha2.radio-msu.net...

This topic was widely discussed before but somehow I still have no idea

how

to fix the problem.

I've a C++ class which resides inside DLL and has some STL members inside. The EXE uses STL vector of my classes and get run time crash on the
destructors in the RTLValidateHeap function.
The knowledge base Q122675 article explains the situation. However the
solution offered by Microsoft on declaring constructor and destructor

inline

does not work. I have the problem on Intel Compiler and STLPort's

version

of

STL.

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.

Doesn't make it any less off-topic because operating systems other
than Windows have similar issues. It is still off-topic. The C++
language does not define libraries at all, let alone dynamic or shared
ones.

It is just plain and simply not a language issue.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq