Salt_Peter wrote:
toton wrote:
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.
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.
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.
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.
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.
