Temporary MFC Objects
Joseph Koral -- jkoral@ftp.com
Wednesday, January 24, 1996
First, I should state my understanding of "undocumented" as it applies =
to MFC. Anything that is private or implementation specific (i.e. =
follows the // implementation comment) is undocumented and subject to =
change in later versions. =20
There are three public methods in CImageList that I'm assuming were =
accidentally left out of the documentation, FromHandle, =
FromHandlePermanent and DeleteTempMap. If you look at the class =
definition, they all fall under the // attributes comment and are not =
implementation specific. Furthermore, these methods are identical in =
purpose to CWnd documented methods of the same name.
Assuming that documentation accidentally left them out, I think there is =
a problem:
Temporary objects that are created from handles are stored in maps and =
deleted during application idle time (there are other times, but it's =
not relevant). Or if you like, each class has a DeleteTempMap for you =
to do it proactively. =20
The global function that frees the temporary maps is AfxUnlockTempMaps =
(found in WINHAND.CPP). Among other things, it eventually calls each =
class' static DeleteTempMap method. Only a few MFC classes will create =
temporary objects, namely CWnd, CGdiObject, CDC, CMenu, and CImageList. =
But AfxUnlockTempMaps doesn't call the static CImageList::DeleteTempMap. =
=20
So unless I'm mistaken, if you create temporary CImageList objects, they =
will slowly consume memory as your app runs.
(On a similar note, why is CAsyncSocket::FromHandle not called =
CAsyncSocket::FromHandlePermanent? Since CAsyncSocket won't create a =
temporary object, using FromHandle is misleading, especially when the =
identical functionality is called FromHandlePermanent in other classes). =
- Joseph
Joseph Koral -- jkoral@ftp.com
Wednesday, January 24, 1996
First, I should state my understanding of "undocumented" as it applies =
to MFC. Anything that is private or implementation specific (i.e. =
follows the // implementation comment) is undocumented and subject to =
change in later versions. =20
There are three public methods in CImageList that I'm assuming were =
accidentally left out of the documentation, FromHandle, =
FromHandlePermanent and DeleteTempMap. If you look at the class =
definition, they all fall under the // attributes comment and are not =
implementation specific. Furthermore, these methods are identical in =
purpose to CWnd documented methods of the same name.
Assuming that documentation accidentally left them out, I think there is =
a problem:
Temporary objects that are created from handles are stored in maps and =
deleted during application idle time (there are other times, but it's =
not relevant). Or if you like, each class has a DeleteTempMap for you =
to do it proactively. =20
The global function that frees the temporary maps is AfxUnlockTempMaps =
(found in WINHAND.CPP). Among other things, it eventually calls each =
class' static DeleteTempMap method. Only a few MFC classes will create =
temporary objects, namely CWnd, CGdiObject, CDC, CMenu, and CImageList. =
But AfxUnlockTempMaps doesn't call the static CImageList::DeleteTempMap. =
=20
So unless I'm mistaken, if you create temporary CImageList objects, they =
will slowly consume memory as your app runs.
(On a similar note, why is CAsyncSocket::FromHandle not called =
CAsyncSocket::FromHandlePermanent? Since CAsyncSocket won't create a =
temporary object, using FromHandle is misleading, especially when the =
identical functionality is called FromHandlePermanent in other classes). =
- Joseph
| Вернуться в корень Архива
|