Re: static class variable allocated at heap
gelbeiche wrote:
class toConnectionProvider
{
static std::map<QCString, toConnectionProvider *> *Providers;
...
}
A provider can register itself in the map:
void toConnectionProvider::addProvider(const QCString &provider)
{
checkAlloc();
Provider = provider;
(*Providers)[Provider] = this;
}
and there is a member function which checks if the map is allocated.
void toConnectionProvider::checkAlloc(void)
{
if (!Providers)
Providers = new std::map<QCString, toConnectionProvider *>;
}
I have the following questions:
- AFAIK Providers is never "deleted" until program exit and usually
I expect a new/delete pair for dynamic memory allocation.
So I guess the idiom above(static class variable allocated at heap)
is not kosher ?!
Why, because some mechanic leak-checker calls it a memory leak? It isn't,
because you can call the code a hundred times and the memory usage doesn't
increase. In fact it is an optimisation, because why go through the map and
destroy things when the only thing that does is release storage that would
be reclaimed anyway when the program exits.
- Is the code above a candidate for refactoring ?
A quick change would be to convert
map<>* Providers;
to
map Providers;
Is it a essential improvement ?
You remove one heap allocation. You remove the check whether this allocation
already took place.
You add one static constructor to call. This happens always, not optionally
when it is used like before. You add one static destructor to call with all
the overhead as described above.
- Another idea would be to make a separate class
toConnectionProviderManager which stores the providers in a container.
Is it a good idea ?
Not worth the hassle, I daresay. Well, maybe for a multithreading-safe
version thereof. ;)
Uli
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]