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.