CString: Bug or limitation?
Ron Birk -- rbirk@ctp.com
Friday, April 05, 1996
-- [ From: Ron Birk * EMC.Ver #2.5.02 ] --
Environment: VC++ 1.52c / Win 95
I have a DLL that recieves a pointer to a CString object from the EXE file.
Both the DLL and EXE have MFC statically linked. The Empty() method is used
on the CString object.
If the CString is allready empty there will be an invalid pointer used to
free some memory. This is because an empty CString have a pointer to a NULL
byte, but because my EXE and DLL are using there own copy of MFC this NULL
byte is in different places. In the Empty() method the internal pointer is
compared to the NULL byte pointer and if they do not match it tries to free
this memory. But this memory is not supposed to be freed when it points to
the MFC NULL byte!!
So is this a bug in MFC or a limitation?
Ron
--
/\/\ Ron Birk Email: rbirk@ctp.com
/ /_ \ Horizontal Solutions Tel: +46 8 744 6119
\ / / Cambridge Technology Partners Fax: +46 8 744 9933
\/\/ Stockholm, Sweden Voicemail: +1 617 374 2081
Dean McCrory -- deanm@microsoft.com
Sunday, April 07, 1996
[Mini-digest: 4 responses]
This is by design. So, I guess in your terms, it is a 'limitation'.
Two different modules (your DLL and EXE, or even two different DLLs) not
only have separate copies of MFC, but also separate heaps (each
C-runtime allocates its own heap). Therefore, it is invalid to allocate
memory in one and free it in another, and except in very limited cases,
it is invalid to create an object with one instance of MFC and destroy
(or otherwise pass it) it in another.
This is what dynamic linking is for. If all your modules dynamically
link to the C-runtime (msvcrt40.dll) and MFC (mfc40.dll), then everybody
shares the same heap and the same implementation. The same rule applies
to 16-bit stuff.
// Dean McCrory
// Team Jakarta
-----From: "Mike Blaszczak"
> So is this a bug in MFC or a limitation?
Neither: it's pilot error.
You can't pass MFC objects back and forth between one DLL and another or
between DLLs and their applications unless you're using AFXDLL. Since you're
not, you can't expect this to work.
.B ekiM
-----From: "VARughese GEOrge"
looks like you are trying to do the wrong thing!!
i mean passing MFC objects across application - USRDLL boundaries...
please remember that if you need to pass MFC object (or MFC derived object)
pointers to or from an MFC DLL, then the DLL should be an extension DLL..
so is it really worth solving this problem?
vargeo
http://ramco_web.ramco.com/vargeo.htm
when i woke up i saw eggs..they were all easter eggs!!
-----From: Jeff Dickey
Ron,
It's a defect, whether as a "bug" (introduced by programming error) or
a misfeatrure. Other frameworks which allow you to create EXEs and DLLs with
per-instance embedded links to the library (such as OWL, zApp, Rogue Wave,
etc.) don't have this problem, and let you pass CString-equivalent instances
merrily hither to yon. Of course, _anybody_ has problems with double deletions,
so you do need to be very clear on who "owns" the memory!
Jeff
| Вернуться в корень Архива
|