Juha Nieminen <nos...@thanks.invalid> wrote
innews:hf0o2g$aut$3@adenine.netfront.net:
James Kanze wrote:
On Nov 28, 3:26 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
Victor Bazarov wrote:
Apparently you need 'A::container' to be a singleton.
See any of the existing implementations of that pattern.
Most simple ones actually create the singleton on demand
(in freestore) and never destroy it.
You mean that if you want to make sure that a static
member is never accessed after it has been destroyed, you
have to allocate it dynamically and purposefully leak it?
That's the usual singleton idiom.
I would have never thought at a programming idiom requires
deliberate introduction of a memory leak into your program.
Is it really the only way?
If one wants the singleton to be available until the program
termination, then one cannot destroy it from inside the
program, it's as simple as that. I would not call this a real
memory leak as any decent OS will reclaim the singleton memory
immediately afterwards, during the process termination.
Of course, one could define a safe order of destruction of all
singletons and ensure that they are destroyed properly before
the program termination, but this would only make the program
slower and more error- prone, with no positive effect
whatsoever.
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