MFC Extension DLL and std::map 
Author Message
 MFC Extension DLL and std::map

Hi,
  I had to build an MFC extension DLL as a kind of plugin ( Explicitly
linked ).
The main app and the DLL had instances of the same class, which used
std::map.
The application invariably crashes in this scenario, somewhere deep in
class _Tree. I had to remove the map and replace it with a less
efficient ( and incorrect ) pair of vectors, in an emergency.

 The app was initially built without the DLL and the code worked just
fine.  I had searched at that time for any clues on the net.
Apparently at least one other person had encountered the same problem.

Quote:
The user writes:

 "My theory is that STL's internal static objects (such as
_Tree<...>::_Nil) are not working properly across the extension
DLL/app boundary, but I am having trouble generating a piece of test
code that convinces me that I completely understand the problem. Has
anybody else already dealt with this problem?  Are some STL classes
off limits within MFC extension DLLs?"

A solution was proposed by another user:
  "Your problem is indeed that the _Nil static member is instantiated
twice, once in the DLL, and once in the main application. This causes
comparisons to _Nil to fail, because a node may be set up with a e.g.
_left pointer to a _Nil in the DLL, and compared to _Nil in the
application, and vice versa. The only workaround we could come up with
is to modify the sources of xtree, which is where the problem occurs,
and to add an inline function that tests, instead of physical equality
to _Nil, logical equality, i.e., whether the right/left pointer is
actually NULL (0).
The modified xtree source is included."

( I can provide the above source code ; but it didn't work for me )

Is someone aware of this? Is there a work around in place? Is there a
better explanation?

Thank you very much,
Cheers



Sun, 16 May 2004 12:48:54 GMT  
 MFC Extension DLL and std::map

Quote:

> A solution was proposed by another user:
>   "Your problem is indeed that the _Nil static member is instantiated
> twice, once in the DLL, and once in the main application. This causes
> comparisons to _Nil to fail, because a node may be set up with a e.g.
> _left pointer to a _Nil in the DLL, and compared to _Nil in the
> application, and vice versa. The only workaround we could come up with
> is to modify the sources of xtree, which is where the problem occurs,
> and to add an inline function that tests, instead of physical equality
> to _Nil, logical equality, i.e., whether the right/left pointer is
> actually NULL (0).
> The modified xtree source is included."

> ( I can provide the above source code ; but it didn't work for me )

> Is someone aware of this? Is there a work around in place? Is there a
> better explanation?

Known bug. For a free fix, see

http://www.dinkumware.com/vc_fixes.html

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Mon, 17 May 2004 00:15:16 GMT  
 MFC Extension DLL and std::map
Hi P.J,
  Thanks. I still have to test this with my DLL. As an added bonus,
the fix in deque revealed a subtle bug in another program.

It is a pity that Microsoft doesn't direct VC++ users to this page.

Cheers,
Sarat

Quote:


> > A solution was proposed by another user:
> >   "Your problem is indeed that the _Nil static member is instantiated
> > twice, once in the DLL, and once in the main application. This causes
> > comparisons to _Nil to fail, because a node may be set up with a e.g.
> > _left pointer to a _Nil in the DLL, and compared to _Nil in the
> > application, and vice versa. The only workaround we could come up with
> > is to modify the sources of xtree, which is where the problem occurs,
> > and to add an inline function that tests, instead of physical equality
> > to _Nil, logical equality, i.e., whether the right/left pointer is
> > actually NULL (0).
> > The modified xtree source is included."

> > ( I can provide the above source code ; but it didn't work for me )

> > Is someone aware of this? Is there a work around in place? Is there a
> > better explanation?

> Known bug. For a free fix, see

> http://www.dinkumware.com/vc_fixes.html

> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com



Mon, 17 May 2004 19:40:33 GMT  
 MFC Extension DLL and std::map

Quote:
> http://www.dinkumware.com/vc_fixes.html

The advice on this page says

Quote:
>>It is always a good idea to apply the latest Microsoft service pack to

upgrade your compiler.
Quote:
>>Many problems quietly disappear when you do so. For example, you can now

get V5.0 SP3 and V6.0 SP3.

The link and text can be updated to V6.0 SP5

Cheers

Stephen Howe



Mon, 17 May 2004 22:18:14 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. How to export a class from Extension MFC dll to another Extension MFC dll

2. a MFC extension DLL in another MFC extension DLL

3. Passing std::set and std::map objects between 2 dlls

4. loading an MFC DLL that was originally an extension dll from a non MFC dLL

5. LNK2001 when trying to link a MFC Extension DLL into another Extension DLL

6. Shell extension using MFC extension DLLs

7. Exporting STL containers (specifically std::map) from DLL?

8. std::map.find() crashing in DLL

9. mem leaks when using std::map in a dll

10. std::map compiler stack overflow when DLL

11. passing std::map based objects from an app to a dll

12. Extension DLLs and message map weirdness

 

 
Powered by phpBB® Forum Software