I'm having a problem with passing a map's address out of a DLL into a user
defined callback (linked into the main exe space).  What seems to be
happening is that a object with a second member (such as map<first,second>)
is having problems on iteration.
The map will return correctly the number of items and appears to function
correctly as long as no iteration is involved.  When you try to iterate, it
works on the first one and then NT throws a memory exception on subsequent
iterators because the iterator object is NULL.

I don't have this problem when it is a vector (and I'm assuming set, etc.).
What makes this more fun is that if I move the user defined callback into
the DLL memory space, the function then works fine.

Thanks,

--
Mike Beard
Merrill {*filter*}
Private Client Architecture

The problem is that the VC++ map class relies on a parametrized red-black
binary tree class to implement the map.  The red-black tree defines a
couple of static data members.  As you know, the static data members will
be instantiated in both the DLL and the EXE.  The map iterators rely on the
values of the static data members to function; the iterators will get
confused when they are constructed in the EXE and used in the DLL, or vice
versa.  This is a serious design flaw in the VC++ red-black tree
implementation.

If you want a standard map that works correctly in these circumstances, I
suggest trying XTL.  We have a free 30-day demo on our website at:

    http://www.deltalogic.com/xtl/demo/demo.htm

One of the example programs that comes with the demo illustrates how you
can pass maps, strings, and lists back and forth from DLL to EXE, with none
of these kinds of problems.

--Bob

====================================================================

DeltaLogic, Inc.                           http://www.deltalogic.com
1537 Kew Road                                   Voice (216) 321-8200
Cleveland Hts, OH 44118-1204                    Fax   (216) 321-6976

Bob,

Thanks for the speedy reply.  At least now I know what I'm up against.

Thanks again,
Mike