singleton class problem

[toton]

Hi,
If I have a singleton class based on dynamic initialization (with new
) , is it considered a memory leak? Anything in C++ standard says about
it ?
And little off - topic question ,
If the singleton is initialized as a static variable , it seems
there is some threading issue . Is it the issue during singleton
initialization only , or during the access also?
If the singleton is per thread basis (then no more singleton though
), and access and life is restricted within the thread, then a static
initialization is safe ?

Thanks
abir

 

[Alf P. Steinbach]

* toton:

Hi,
If I have a singleton class based on dynamic initialization (with new
) , is it considered a memory leak?

Generally the term "memory leak" refers to /repeated/ memory allocations
without corresponding deallocations, a worsening over time.

Anything in C++ standard says about it ?

No, it doesn't define "memory leak".

And little off - topic question ,
If the singleton is initialized as a static variable , it seems
there is some threading issue . Is it the issue during singleton
initialization only , or during the access also?

Both, although the current C++ standard does not address threading issues.

However, take a look at Boost's thread local storage class.

If the singleton is per thread basis (then no more singleton though
), and access and life is restricted within the thread, then a static
initialization is safe ?

Define what you mean by "safe", best with some actual code.

 

[Nate Barney]

If I have a singleton class based on dynamic initialization (with new
) , is it considered a memory leak?

If you maintain a pointer to every dynamically allocated region of
memory, there is no leak. A leak occurs when you have allocated memory
or another resource and no longer have a pointer/handle to it.

I got this definition from one of Scott Meyers' books, and it seems
pretty good to me.

Nate

 

[Salt_Peter]

Hi,
If I have a singleton class based on dynamic initialization (with new
) , is it considered a memory leak? Anything in C++ standard says about
it ?

Yes, its a memory leak. What that entails is undefined. However, there
is no excuse for such a condition since a simple singleton using a
shared_ptr is the way to go. There are other benefits that some
shared_ptrs brings to the picture as well (ie: boost::shared_ptr). Read
some of the Posts here to find out what those are.

And little off - topic question ,
If the singleton is initialized as a static variable , it seems
there is some threading issue . Is it the issue during singleton
initialization only , or during the access also?

All statics are affected by access if you use threads. That too has a
simple solution. write a class that locks / unlocks for you.

If the singleton is per thread basis (then no more singleton though
), and access and life is restricted within the thread, then a static
initialization is safe ?

Ask in an appropriate newsgroup that does threads.
Typically, static variables have internal linkage. In C++ thats
considered deprecated. A better alternative is to use statics in
namespaces or even in anonymous namespaces.

namespace whatever
{
static int n = 99;
static create() { ... }
}

Such a strategy is better design since a static variable named var in
one file is not the same static var in another. internal linkage =
static file linkage.

 

[vijay]

Hi,

If you are working with multithreading then Singleton implemention will
have problem if you are not using locking mechanism.Two or more thead
might be accessing Static function and crate more then one instance of
Singleton class. But locking will hit performance. So double check
locking is advised.
You can get more informaton ragarding doublechecked locking
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

 

[toton]

Yes, its a memory leak.

Confused
Got two answer, one says yes the other no!
I always get two opposite answers for a question related to C++.
It is a memory leak from program's point of view. But doesn't OS cleans
the memory ?
What happens when I run new based singleton class several times. Will
the OS consume all
of the system memory (RAM) ?
confused again, and leaving the topic here (as, because people will say
it is off topic ).

What that entails is undefined. However, there
is no excuse for such a condition since a simple singleton using a
shared_ptr is the way to go. There are other benefits that some
shared_ptrs brings to the picture as well (ie: boost::shared_ptr). Read
some of the Posts here to find out what those are.

Not sure how shared_ptr will be able to do it from outside. Searching
the newsgroup is not giving any hint.
So to have a second way, I have a near-singleton class. Which I know
standard enough so that no one creates a duplicate one (by convention,
not by design) . It is just a regular class and has a virtual
destruction, which gets called in program termination. In my case, it
is QApplication from Qt.
Now I have a few other "singleton class" by design. i.e they have
private ctor, copy ctor and copy assignment operator.
Now If I remove the singleton static pointer & get method, and make
them friend of QApplication (it is just a class in this context, not
off topic as it is a Qt class). and add them as member of QApplication.
Then I can delete them in usual way (with shared ptr or move_ptr or
even simple raw ptr) in QApplication destructor.
So, I don't have the problem of having multiple instance of those
"pseudo singleton classes", while only a single instance of
QApplication will keep track of it.
Anyone do this kind of thing (i.e clubbing several non-constructible,
non-copyable, non assignable classes, with a friend class, which has
the role of constructing & destructing them)
May be it is little similar to the Stroustrup's way of making a final
class.

All statics are affected by access if you use threads. That too has a
simple solution. write a class that locks / unlocks for you.

here i have doubt about static linkage. What it actually refers ?
unlike object ,class members (i.e static members ) are one per class (i
or per class / per thread or something else). i.e for static only one
"memory location" (may not be an appropriate term, but hope conveys the
meaning) location per application ( or per thread ? ) If it is per
application, then not a problem for me, but otherwise yes. i.e my
requirement is, anywhere from the application &my_class::my_static_var
to return same value, irrespective of thread or anything else.

 

[Andre Kostur]

Confused
Got two answer, one says yes the other no!
I always get two opposite answers for a question related to C++.
It is a memory leak from program's point of view. But doesn't OS
cleans the memory ?

What the OS does with the allocated memory after the program ends isn't
C++'s problem. So strictly speaking, I would say that you have a memory
leak in your program. Your object was not deleted by you. Perhaps
wrapping it into a smart pointer of some description (std::auto_ptr ?).

What happens when I run new based singleton class several times. Will
the OS consume all
of the system memory (RAM) ?

Huh? How do you "run new based singleton class serveral times"? If you
can have multiple instances of the object, it's not a singleton
anymore....