Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Any memory leak for this Singleton Implementation

Reply
Thread Tools

Any memory leak for this Singleton Implementation

 
 
Axter
Guest
Posts: n/a
 
      01-14-2006

Jay Nabonne wrote:
> On Fri, 13 Jan 2006 12:24:34 -0800, tomgee wrote:
>
> > I saw it many times,
> >
> > // T.h:
> >
> > class T
> > {
> > public:
> > static T* instance();
> > private:
> > T() {}
> > ~T() {}
> > static T* smInstance;
> > };
> >
> > // T.cpp:
> >
> > T* T::smInstance = NULL;
> >
> > T* T::instance()
> > {
> > if (smInstance == NULL)
> > smInstance = new T();
> >
> > return smInstance;
> > }
> >
> > But I suspected there is a memory leak, because there is a free() call
> > for the memory allocated by new().
> >

>
> Not only does it leak, but the destructor won't be called.
>
> If you don't use a pointer, you can make it auto-destructing:
>
> class T
> {
> public:
> static T& instance();
> private:
> T() {}
> ~T() {}
> };
>
> // T.cpp:
>
> T& T::instance()
> {
> // constructed when first executed. Destructed when program exits.
> static T t;
>
> return t;
> }


If you use the above method, and the singleton gets called by a global
object's destructor that's in a different translation unit, it will
result in undefined behavior, because there's no garantee of the order
of destruction for global objects in multiple translation units, IAW
C++ standards.

If the singleton is not called from any global object's destructor,
then the above implementation would be the safer and cleaner method.

 
Reply With Quote
 
 
 
 
JustBoo
Guest
Posts: n/a
 
      01-14-2006
On 13 Jan 2006 23:48:51 -0800, "Axter" <(E-Mail Removed)> wrote:
>If you use the above method, and the singleton gets called by a global
>object's destructor that's in a different translation unit, it will
>result in undefined behavior, because there's no garantee of the order
>of destruction for global objects in multiple translation units, IAW
>C++ standards.
>
>If the singleton is not called from any global object's destructor,
>then the above implementation would be the safer and cleaner method.


Thank you. That is the first rational explanation that I can
*remember* to counter all the hand-wringing that goes with
Singletons. Mind you, I have felt queasy at times relying on an
unreliable OS to clean up myself. "But we have deadlines to
meet dammit." It's always a balance.

I've used them for years with no trouble except the angst from other
engineers. I've used them to help get younger engineers design's
up and running quickly.

I'll 'nick' the above if you don't mind.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Singleton object vs. enhancing singleton class Paul McMahon Ruby 3 06-09-2008 06:05 AM
Singleton Modules rather than Singleton Classes Trans Ruby 12 09-14-2007 06:45 AM
Singleton - Whether Cloneable overrides Singleton Proton Projects - Moin Java 4 03-27-2007 02:59 AM
501 PIX "deny any any" "allow any any" Any Anybody? Networking Student Cisco 4 11-16-2006 10:40 PM
Singleton classes and Singleton pattern Wilhelm Ruby 1 10-11-2006 01:08 PM



Advertisments