Re: What MFC Objects Can't be created on the Stack?
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Tue, 08 Aug 2006 14:13:58 -0400
It is not the responsibility of the programming language to tell you how to manage kernel
resources. As I pointed out in an earlier response, different applications have different
strategies for resource management, and neither the language nor the operating system can
tell you which strategy is best for you, nor can they infer that the reason you have 20
fonts is because you meant to have just one but didn't know how to program, vs. the fact
that you well and truly intended to have 20 fonts. But not 21.
If you have a solution to how this can be done, a lot of people would be interested. It
is called in the trade "DWIMware", that is, software that does what I mean, not what I
wrote.
By the way, .NET doesn't handle this either. In .NET, you can still create 20 fonts when
you meant to have only 1. Not even .NET can tell that you intended to have only 1 font
but didn't know what you were doing.
joe
On Tue, 8 Aug 2006 09:40:26 -0500, "Peter Olcott" <olcott@xxxxxxx> wrote:
Joseph M. Newcomer [MVP]
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:c2agd21biar3esf5meh5thia4eu6ds8sac@xxxxxxxxxx
See below...
On Mon, 7 Aug 2006 22:58:35 -0500, "Peter Olcott" <olcott@xxxxxxx> wrote:
****
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:8dvfd21sutlsoavnq19atoels3d58i4aqc@xxxxxxxxxx
See below...
On Wed, 2 Aug 2006 18:42:36 -0500, "Peter Olcott" <olcott@xxxxxxx> wrote:
****
"Dan Bloomquist" <public21@xxxxxxxxxxx> wrote in message
news:4AaAg.6946$Oh1.3909@xxxxxxxxxxxxxxxx
Peter Olcott wrote:
I need to be able to change the currently selected font without creating
any
resource leak.
See if these assumptions are correct:
(1) The resource associated with a CFont is only destroyed when the CFont
object goes out of scope.
No, you can call DeleteObject( ) and then CFont becomes an empty shell.
That would make things simpler. What happens if you do this more than once
in
a
row?
If you attempt to DeleteObject if there is no object, you might get an
assertion failure.
But as long as you DeleteObject before the next CreateFont[Indirect], you
can
do this as
many times as you feel like, possibly hundreds of times in a loop for that
matter
****
****
(2) Calling NewFont.CreateFontIndirect() twice while keeping NewFont in
scope
creates one extra instance of NewFont that does not get properly
destroyed.
No. Attach( ) will assert unless you have a previous DeleteObject( ).
I have no idea what this means.
This is a critical concept. You really need to understand it.
When you create a C++ object (wrapper), you may or may not get an associated
kernel object
that it wraps. It depends on the object and the meaning of its constructor.
Ultimately,
however, a function called Attach is called that takes as input a kernel
handle to a
kernel object, and binds it to the wrapper class. This tests to make sure
that an
existing object is not already wrapped by the C++ object, and if one is,
there
is an
ASSERT statement that reports this fact.
There is a corresponding operation, Detach, which breaks the association
between the
kernel object and the C++ object, removing all knowledge of the kernel
object
from the
wrapper. Following a Detach, which returns the kernel handle of an object,
the object
exists, but the C++ wrapper no longer knows about. Thus, if you Detach you
have
responsibility for tracking the handle in some way, but if the C++ wrapper
leaves scope
there is nothing for it to destruct, and its destructor will not delete the
kernel object
because it has no idea it exists.
Similarly, there are operations that can destroy the underlying kernel
object,
such as
CGdiObject::DeleteObject (subclassed it is CFont::DeleteObject) or
CWnd::DestroyWindow.
These allow the C++ object to remain while breaking the connection with the
kernel object
and destroying the kernel object.
I only need to simplest possible way to attain the required functionality. It
seems that there are far too many nuances to pay attention to. Microsoft made
a
big mistake by requiring one to fully understand all of the nuances of the
underlying infrastructure to accomplish what should otherwise be relatively
simple tasks. Its good that they finally got the Borland guys to untangle this
ungodly mess with the design of the .NET architecture.
The nuances arise when you try to exercise paradigms outside the basic design
goals of
MFC. The handle/wrapper work transparently up to a point, and you just
happened to choose
an initial project that is beyond that point. At that point, it isn't a set
of subtle
nuances, it is very clear and well-defined behavior.
****
How is my design outside of the basic design goals of MFC?
Why can't this housekeeping stuff all be handled behind the scenes
transparently?
Couldn't the Win32 functions that MFC wraps be designed to handle their own
housekeeping?
*****
Some constructors will both create a C++ object and its underlying kernel
object; for
example,
CBrush br(RGB(...));
declares a variable and also creates a kernel object to go with it; and is
equivalent to
CBrush br;
br.CreateSolidBrush(RGB(...));
but other than pens and brushes (at the moment I'm drawing a blank on other
types of
objects for which this might be true), most of these wrappers simply create
a
C++ object
and you must create the kernel object later. You are free, of course, to
subclass one of
these and provide subclass constructors that will also create kernel
objects,
but that's a
fine point.
******
So Microsoft did not design its wrapper classes to behave consistently?
The wrapper classes behave consistently; the issue is whether or not there are
convenient
constructors for the simple cases. You don't need to use the constructors if
you don't
want them, and the classes are then completely consistent. But having
constructors of the
type I described, for pens and brushes in particular, is very convenient.
Think of them
as extensions to the basic model.
*****
Joseph M. Newcomer [MVP]Joseph M. Newcomer [MVP]
Best, Dan.
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: What MFC Objects Can't be created on the Stack?
- From: Alexander Grigoriev
- Re: What MFC Objects Can't be created on the Stack?
- From: Tom Serface
- Re: What MFC Objects Can't be created on the Stack?
- References:
- Re: What MFC Objects Can't be created on the Stack?
- From: Joseph M . Newcomer
- Re: What MFC Objects Can't be created on the Stack?
- From: Peter Olcott
- Re: What MFC Objects Can't be created on the Stack?
- From: Joseph M . Newcomer
- Re: What MFC Objects Can't be created on the Stack?
- From: Peter Olcott
- Re: What MFC Objects Can't be created on the Stack?
- Prev by Date: Re: What MFC Objects Can't be created on the Stack?
- Next by Date: Re: What MFC Objects Can't be created on the Stack?
- Previous by thread: Re: What MFC Objects Can't be created on the Stack?
- Next by thread: Re: What MFC Objects Can't be created on the Stack?
- Index(es):
Relevant Pages
|