Re: Singleton_pattern and Thread Safety
On Dec 10, 3:56 pm, Leigh Johnston <le...@i42.co.uk> wrote:
On 10/12/2010 15:29, James Kanze wrote:
On Dec 10, 1:16 pm, Leigh Johnston<le...@i42.co.uk> wrote:
On 10/12/2010 09:52, James Kanze wrote:
On Dec 9, 5:05 pm, Marcel M ller<news.5.ma...@spamgourmet.com> wrote:
Pallav singh wrote:
Note that the above still risks order of destruction issues;
it's more common to not destruct the singleton ever, with
Singleton* ourInstance =&Singleton::instance();
if (ourInstance == NULL)
ourInstance = new Singleton;
(This solves both problems at once: initializing the variable
with a call to Singleton::instance and ensuring that the
singleton is never destructed.)
James "Cowboy" Kanze's OO designs includes objects that are never
destructed but leak instead?
And where do you see a leak?
Is that a serious question?
Yes. There's no memory leak in the code I posted. I've used it
in applications that run for years, without running out of
The only real difference between the two programs below is the amount of
int* p = new int;
int* p = new int;
p = new int;
Arguably, there's no memory leak in either. A memory leak
results in memory use that increases in time. That's the usual
definition of "leak" in English, applied to memory, and it's the
only "useful" definition; if the second line in the above were
in a loop, you would have a leak.
Other definitions of memory leak are possible---I've seen people
claim that you can't have a memory leak in Java because it has
garbage collection, for example. But such definitions are of no
practical use, and don't really correspond to the usual meaning.
A singular memory leak (one that is not repeated so doesn't
consume more and more memory as a program runs) is still
a memory leak.
I will ignore the predictable, trollish part of your reply.
In other words, you know that your position is indefensible, so
prefer to resort to name calling.