Re: intentional leak w/ pooled objects
Michiel.Salters@tomtom.com wrote:
andrew_nuss@yahoo.com wrote:
I am using pooled objects that do have virtual members but
no constructor and an empty virtual destructor and using
placement new syntax to invoke the constructor to initialize
the v-table.
That's probably fast; most compilers do a good job at inling empty
functions.
That depends. If he's calling through a pointer, the destructor
won't be inlined, because it's virtual. Also, if the only time
he cleans up is at the end, in a loop, some compilers won't get
rid of the loop. Of course, if he only cleans up at the end,
then performance won't be a problem. And if he immediately
constructs a new object after cleaning up, it is pretty unlikely
that it be a problem either.
My question is whether there are compilers that do some kind
of bookkeeping for objects that have virtual methods
requiring that individual destructors be called to avoid
leaks.
Perhaps, but another question that's harder to answer and more
important:
will there be? (Because today you'll understand why it fails.
In 5 years, you won't)
Realistically, there won't be:-).
Which doesn't mean that there isn't a problem anyway.
Presumably, anyone reading the code will know C++, and know the
rules, and will have a great deal of difficulty understanding
what's going on if the rules aren't followed.
Of course, if the profiler says that you've got to do it, you
do. And you end up writing a lot of comments explaining exactly
what you are doing, and why, because it is so unusual.
I would like to be able to effectively destroy the objects
simply by freeing the memory in which the objects were
placed, and avoiding
Why? If it's truely empty it's quite likely going to be
inlined and thus instant. After all, you're calling the
destructor directly ( p->~X(); ) and the compiler should be
able to figure that out.
If you call p->~X(), and the destructor is virtual, the compiler
will not be able to figure anything out. If, immediately after,
you then call free(p) or operator delete(p), of course, you
don't care -- either of those will take a lot longer than a
virtual function call anyway.
About the only time I can see it making a difference is if you
are dealing with a large pool of rapidly changing agents --
objects with no data members. If you can guarantee that all of
the derived classes follow the rules (no data members), and are
of the same size, you can probably get away with allocating one
big block, constructing using placement new in that block, and
never calling destructors. Still, I'd need some very strong
solution would work, before I'd go that route in classical C++.
It is a frequent case when using garbage collection. Normally,
at least the way I configure it, the garbage collector never
calls destructors. But there, you expect it; it's not really an
exception to the rule.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]