Re: Singleton_pattern and Thread Safety
On 13/12/2010 10:12, James Kanze wrote:
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
something like:
namespace {
Singleton* ourInstance =&Singleton::instance();
Singleton&
Singleton::instance()
{
if (ourInstance == NULL)
ourInstance = new Singleton;
return *ourInstance;
}
}
(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
memory.
Bullshit. If the code was in a DLL and the DLL was loaded/unloaded
multiple times the leak would be obvious.
The only real difference between the two programs below is the amount of
memory leaked:
int main()
{
int* p = new int;
}
int main()
{
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.
Bullshit. If the code was in a DLL and the DLL was loaded/unloaded
multiple times the leak would be obvious.
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.
Bullshit.
Your singleton method is a leak and has unspecified construction order
across multiple TUs. It is hogwash.
/Leigh