I have code that goes something like this:
/* DLL.CPP* /

DLLFoo(std::vector<std::string>& words)
{
    for(...)
    {
        std::string s=...;
        words.push_back(s);
    }

/ *DRIVER.CPP* /

foo()
{
    std::vector<std::string> words;
    DLLFoo(words);

This code crashes in operator delete of "words" when the object goes out of
scope. I am under the impression that this is due to the fact that when the
strings are pushed into the vector on the DLL
side, a DLL linked list of memory is used to allocate them, and when the
object is destroyed on the
driver side the attempt is made to delete it from the local memory pool.
1) Is this a reasonable explaination?
2) Is there an elegant way to solve this problem?

For now I defined an DLLNewVec function which allocates the vector on the
DLL side, and DLLDeleteVec which deletes it on the DLL side like this:
foo()
{
    std::vector<std::string>* pwords=DLLNewVec();
    DLLFoo(*pwords);
    DLLDeleteVec(pwords);

Is there a more elegant solution?
Thanx,
max.

Yes.

Yes. Link both against the DLL version of the C-Runtime (instead of the
static version).

Brad

However, note that you will NEVER be able to mix Debug and Release builds.
They must both be either Debug or Release.

--
Reginald Blue                   | Opinions expressed here do not
Natural Language Understanding  | necessarily represent those of
Unisys Corporation              | my employer.
--------------------------------+-------------------------------

NL technology,speech application| My email address is wrong, you
development training, see:      | need to remove the obvious.
http://www.speechdepot.com/     +-------------------------------

I am not clear about the context of the above statement.
I have mixed debug & release libraries many a times for debugging
purposes.
I did not have any problems.

--
cheers,
Shiva
http://www.slack.net/~shiva/
clc++ FAQ : http://www.cerfnet.com/~mpcline/c++-faq-lite/

Problems can arise if you have dlls which have different methods
exported based on DEBUG or RELEASE build. Then the ordinals go haywire
and you might have problems. Also, if you are using any external
libraries (like MFC or Objective ), then you might have problems too.

--
Girish Bharadwaj [mvp].
Please do not email queries to me.
Post them in newsgroups.
Thank you.

The context was with respect to having one shared heap (so that exporting a
vector from a DLL will work.)

The real problem is allocating memory in a DLL and deallocating it in the
EXE (or another DLL).  There is never a guarantee that they are all using
the same heap (but you can work very hard to try to make sure they are.)

My opinion is that one should AVOID this kind of behavior AS MUCH AS
POSSIBLE.  (i.e. never do it.)

However, given that people do do this, I try to warn that you can't mix a
debug EXE with a release DLL (or whatever) because they'll (again) be using
different heaps (and different heap deallocation strategies.)

YMMV

By the way, if you want to be real fancy (so as to have your cake and eat it
to) write your own allocator class to work with the vector which uses a safe
mechanism for allocation and deallocation like VirtualAlloc, LocalAlloc,
GlobalAlloc, or CoTaskMemAlloc.

(and if someone does write this, share it with the world so we can all stop
living in this nightmare.  ;-)

--
Reginald Blue                   | Opinions expressed here do not
Natural Language Understanding  | necessarily represent those of
Unisys Corporation              | my employer.
--------------------------------+-------------------------------

NL technology,speech application| My email address is wrong, you
development training, see:      | need to remove the obvious.
http://www.speechdepot.com/     +-------------------------------

I always add a 'd' to the end ofthe debug version dll file, and modify the
export header for the dll as follows:

// control whether functions are declared as imported or exported
#ifdef YOUR_DLL_EXPORTS
 // define the DLL functions as exported
 #define YOUR_DLL_API __declspec(dllexport)
#else
 // define the DLL functions as imported
 #define YOUR_DLL_API __declspec(dllimport)
// and link in a version of the DLL
 #ifdef _DEBUG
  // link in the debug version
#pragma comment(lib, "your_dlld.lib")
 #else
  // link in the release version
#pragma comment(lib, "your_dll.lib")
 #endif
#endif

That way i'm always using either all Release or all Debug versions.

Note: I also got away with mixing Debug & Release versions for a while.  But
it IS dangerous, and i eventually ran into problems.  Fix your code now
before a nightmare hits you two weeks before deadline.

DanL