Has anyone else had problems getting an STL map to work in a .dll? It should work I think. It doesn''t.. Let me explain. I''m trying to implement a pluggable factory for loading different kinds of image files. The .dll is dynamically loaded and contains all the rendering stuff. When I load the ''driver'' from my main program I get an access violation, and a file related to the STL map shows up showing me where the error occurs.. The static objects which register themselves automatically in the pluggable factory design cause the STL error... Funny thing is, the exact same code works in the main .exe.. Any ideas?

hi,

i think the STL itself isnt the problem. when you have a dll, all objects,funcs and variables in the dll which are accessed through your main exe, have to be declared using your declspec macro, like MY_DLL_API or something... if you dont declare it like this, you will get an access violation or something...

you can compile it, because the variable is in the header file of the dll, but the process cant reach it at runtime.


any other ideas?


Edited by - filefor on January 13, 2001 6:05:40 AM

Hi!

Sorry for not being able to post a solution, but I just posted to say that I''ve run into the problem as well. Not with maps, but with the (STL) string class.

I could safely use STL inside the main program, and inside the DLL, but if I tried to use a STL template/class as a parameter for an exported (from the .DLL) function, then I''d get a violation (I think it compiled without problems).

I think the problem has to do with where the memory is allocated vs. where it is deallocated (I ran my code under Boundschecker and it said something along those lines).

A solution, albeit very tedious, would be to append some declspec export thingie to the STL headers files, but this would ofcourse only work on your local version..

If anyone knows of a better solution (there must be!) I''d be very grateful for an answer too!

Cheers,
Magnus

Note that .DLLs and .EXEs may use different heaps to allocate memory. So if you allocate memory in your .DLL and then pass a pointer on the call stack to you .EXE, that pointer is not a valid heap location. STL has no knowledge of Win32 Heaps (or DLLs for that matter).

Read the MSDN docs for the function GlobalAlloc().
To pass valid pointers from .DLL to .EXE, use this patten:

// Allocate the buffer
HANDLE h = GlobalAlloc( GMEM_ZEROINIT, dwBytes );

// Nail it down so Windows doesn''t move it around.
void* p = GlobalLock( h );

// Now do stuff with the block of memory. Pass it to a
// DLL if you want. Write to is directly, even typecast it
// as some obscure object.

// Unlock it so Windows can blast it to the swap
// file or anywhere it can go.
GlobalUnlock( h );
p = NULL;

// Give the memory back to Windows so other apps can use it.
GlobalFree( h );
h = NULL;

Note that STL containers have allocators so that you can specialize the memory allocation. You might be able to derive your own template class from the default STL allocator so that it uses Win32 API functions to allocate memory.

Hi Marsupial!

An interesting point. I thought that just because a .DLL loads into the calling process'' adress space things like these couldn''t occur..

I guess it''s time to pull out Richter again, and start checking where my memory is being allocated!

Cheers,
Magnus