Re: static class variable allocated at heap
gelbeiche <info@randspringer.de> writes:
a project I'm involved in has code in the form:
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 ?!
That depends on your definition of "kosher". If the only resource that
map locks is memory, and the operating system reuses memory a process
has allocated when the proces terminates, then there I don't see a
real problem.
- 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 ?
That again depends. It certainly makes the code simpler, so as a rule
of thumb, it's a good thing. On the other hand, every process will now
have such a map, even if it wouldn't need it; I can't tell whether
that is acceptable.
- Another idea would be to make a separate class
toConnectionProviderManager which stores the providers in a container.
Is it a good idea ?
Only if you are going to need it.
- What other solutions come to mind when considering such code ?
That depends on the problem you have with it.
I have a problem with the variable Provider in
toConnectionProvider::addProvider(). My solution would be to eliminate
it.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]