Re: Order of destruction of static members and static objects
On Dec 8, 6:16 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
James Kanze <james.ka...@gmail.com> wrote in news:7c0974d7-da79-42d7-
add9-9a0a437c4...@u7g2000yqm.googlegroups.com:
On Dec 7, 6:09 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
James Kanze <james.ka...@gmail.com> wrote in news:0cca4033-dfff-4c8f-
a33e-7baebbe6c...@j35g2000vbl.googlegroups.com:
[...]
This is a typical confusion of the goal and the means.
The "memory leak" concept is just a means used for
making the programs better, and not a goal in itself.
On the programs I work on, a memory leak is a fatal
error. This isn't a memory leak, however, by any
definition of the word.
Sure it is, a conceivable definition is just "anything
flagged as a memory leak by the diagnostic tool I happened
to use".
But does any tool flag this as a memory leak? There's still
a pointer to the memory, so it is at most a "possible memory
leak".
MSVC++ Debug heap facility (guided by _CrtSetDbgFlag() et al.) is
reporting things like this:
Detected memory leaks!
Dumping objects ->
{59831} normal block at 0x0C061168, 36 bytes long.
Data: < =CD=CD=CD=CDUI =CD=CD=CD=CD=CD> 00 00 00 00 CD CD CD CD 55 49=
00 CD CD CD CD CD
{59830} normal block at 0x0C0610E8, 68 bytes long.
Data: <=D8m =D8m > D8 6D 03 0C 08 05 06 0C D8 6D 03 0C 00 00 0=
0 00
{59803} normal block at 0x0C060588, 36 bytes long.
Data: < =CD=CD=CD=CDUI =CD=CD=CD=CD=CD> 00 00 00 00 CD CD CD CD 55 49=
00 CD CD CD CD CD
{59802} normal block at 0x0C060508, 68 bytes long.
...
If there is still a pointer to the object with static lifetime,
I'd consider calling it a leak an error. Quality leak detecters
(like Purify) make the distinction. (To be fair to Microsoft,
the debug leak detector is just a simple hack, to help a little.
I don't think Microsoft claims that it is complete and thorough.
I suspect that it just looks at the heap and reports unfreed
objects, without trying to determine whether there are pointers
to them or not---the latter can be a major undertaking without
access to the source. But they really should change the label
to something like: "unfreed memory (possible leak?)".)
As far as I know, it reports all blocks which have been
obtained from the heap, and not explicitly freed by the time
of check. A thing of interest is that it does not call them
"possible memory leaks".
In fact, what it detects is unfreed memory, and not leaks.
Which is something useful, not too difficult to do, with little
or no impact on the runtime. (Programs under Purify run
significantly slower.) But they should correct the label.
--
James Kanze