Subject: Misc Windows findings, q's and propositins (longish)
From: Mike Nordell (tamlin@algonet.se)
Date: Sun Nov 26 2000 - 22:32:12 CST
Another Purify run (a fun tool) displayed a handle leak (a region handle was
never released) in Win32 graphics why I fixed it, though it isn't committed
yet.
While looking around this file (and the Purify log) I noticed some strange
things, like GR_Win32Font::measureUnRemappedChar isn't using its membed
m_defaultCharWidth but instead sets the returned width to zero if none is
found.
Is this the correct behaviour? If so, I'd like to remove that unused member.
If it on the other hand is incorrect, does anyone know why the use of the
member m_defaultCharWidth was patched away? (gr_Win32Graphics.cpp(730))
Also, there's a leaked font (more likely one per used font in the doc, but I
haven't verified that just yet). It's returned from
GR_Win32Graphics::findFont and stored in fp_TextRun::m_pFont inside the
function fp_TextRun::lookupProperties.
It's obvious that this bug have been present "forever" since the
GR_Win32Font doesn't have a destructor to delete it's contained FONT handle!
Some explanation might be in place:
In Windows you have a "thingie" called Device Context (DC) that you "Select"
stuff into. One of these "things" are font handles. A DC can (as expected?)
only contain one font handle at a time, and as soon as you "Select" a new
font into the DC the old handle is free to be deleted, but you may *never*
delete a font (or any other gfx object) that's currently "selected" into a
DC. Also, a gfx object (including a font) may *never* be selected into more
than one DC at one single time.
This makes it (currently) impossible to release the font handles in the
d'tor of GR_Win32Font since it hasn't got a clue wether it's currently
selected into a DC or not. Ergo: it's leaked.
My proposal is that we add a member to GR_Graphics holding a pointer to the
currently "set" GR_Font. Add a virtual function to GR_Font so GR_Graphics
can inform it of when it's removed from a GR_Graphics, and a virtual
function to GR_Graphics so a font can inform it that it's deleted.
The added functions should be implemented using an "Acquaintance" [1] as to
*only* allow the acquaintance to use it.
This way we *can* add cleanup code even for fonts.
Does anyone see an obvious flaw in my reasoning?
1. Acquaintance.
As it's easier to describe it by an example, have a look at the following:
Class A would like to grant selective friendship to B (only allowing B to
call <n> of it's private member functions), in this case allowing B to only
call A::private1. Usually this is impossible, but as always in C++ you can
solve it by adding another level of indirection.
class B;
class A
{ // default access priv. is "private"
void private1();
void private2();
class InnerA {
friend class B;
static void private1(A& a) { a.private1(); }
}
friend InnerA;
};
By this B is granted access to only A::private1 by calling it like
A::InnerA::private1(a_instance);
It's also not adding *any* extra code for release builds for a reasonably
decent compiler (ymmv).
I've also found (loads) of other leaks, but I think thay can wait. :-)
Cheers,
Mike - please don't cc
This archive was generated by hypermail 2b25 : Sun Nov 26 2000 - 22:32:17 CST