Re: static class variable allocated at heap
gelbeiche wrote:
A quick change would be to convert
map<>* Providers;
to
map Providers;
Is it a essential improvement ?
I should (further to my previous post) point out what can be one
possible flaw with having a function that creates a static instance and
returning a reference to it. But it is only a possible flaw and if it
doesn't apply then go ahead and use it.
The flaw is that although you now have control over the order of
construction of your singleton objects, you do not have any control
over their destruction.
An example of this could well be prevalent in your class: if libraries
are loaded with dlopen() and objects from them are added to your map,
and then later the libraries are closed with dlclose(), all the objects
in your map will be invalid. This won't be a problem unless your map
makes some attempt to access them, including trying to delete them.
(Maybe they are shared_ptrs). But if you are not controlling the
destuction order, you cannot determine what gets deleted first. You may
not consider it a major problem if your application seg-faults when it
is closing down anyway (I suppose you can always delete the core file)
but it's more of a "bug" than the leak-issue).
If no singleton relies on the existence of anything else to exist at
the time of its destruction then it is fine.
My own rule is generally to avoid singletons. Incredible how I was able
to eliminate so many singletons that it turned out didn't need to be
singletons after all. Actually there is one singleton - a table of
dynamically-opened libraries.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]