dev-cpp-users

[Dev-C++] singleton pattern implementation.

[Laura L. <lau...@gm...>]

Hello,

I have a question about the next implementation of the singleton patter, if
I don't do "delete sc1" in main, is there a memory leak?  the problem is
that if I do in the destructor "delete single"  it produces an infinite
loop.

How could I free the memory associated to the variable single?

Thank you.

class Singleton
{
private:
    static bool instanceFlag;
    static Singleton *single;
    Singleton()
    {
        //private constructor
    }
public:
    static Singleton* getInstance();
    void method();
    ~Singleton()
    {
        instanceFlag = false;
    }
};

bool Singleton::instanceFlag = false;
Singleton* Singleton::single = NULL;
Singleton* Singleton::getInstance()
{
    if(! instanceFlag)
    {
        single = new Singleton();
        instanceFlag = true;
        return single;
    }
    else
    {
        return single;
    }
}

void Singleton::method()
{
    cout << "Method of the singleton class" << endl;
}

int main()
{
    Singleton *sc1;
    sc1 = Singleton::getInstance();
    sc1->method();

    return 0;
}

Re: [Dev-C++] singleton pattern implementation.

[Chris M. <lor...@gm...>]

On 9/27/07, Laura Lozano <lau...@gm...> wrote:
> Hello,
>
> I have a question about the next implementation of the singleton patter, if
> I don't do "delete sc1" in main, is there a memory leak?  the problem is
> that if I do in the destructor "delete single"  it produces an infinite
> loop.

I'm not speaking from experience, but just thinking aloud.

You don't need to call delete in the destructor.  Remember, a class is
literally just a bunch of locations in memory.  If the destructor has
been called, delete has already been called (externally to the
destructor) as well.  IIRC, it's your job to free all pointers to
locations in memory that are handled by the class in the destructor,
since those won't be freed automatically by delete.

> How could I free the memory associated to the variable single?

Perhaps use free(single)?  I'm not sure, I know there are consequences
to mixing new/delete and malloc/free, but from my (rather limited)
knowledge I know that free() will just release memory back to the
system.

> Thank you.
>
> class Singleton
> {
>
private:
>  static bool instanceFlag;
>  static Singleton *single;
>  Singleton()
>  {
>
//private constructor
>  }
> public:
>  static Singleton* getInstance();
>  void method();
>  ~Singleton()
>  {
>  instanceFlag = false;
>  }
> };
>
> bool Singleton::instanceFlag = false;
> Singleton* Singleton::single = NULL;
> Singleton* Singleton::getInstance()
> {
>  if(! instanceFlag)
>  {
>  single = new Singleton();
>  instanceFlag =
true;
>  return single;
>  }
>  else
>  {
>  return single;
>  }
> }
>
>
void Singleton::method()
> {
>  cout << "Method of the singleton class" << endl;
> }
>
> int main()
> {
>  Singleton *sc1;
>  sc1 = Singleton::getInstance();
>  sc1->method();
>
>  return 0;
> }
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE:
> http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
>


-- 
Registered Linux Addict #431495
If You Know What's Good For You, You'll Install Linux
John 3:16!

Re: [Dev-C++] singleton pattern implementation.

[Younes O. <ou...@ei...>]

Hello,

The question to ask: is there a need to release the memory reserved for
the singleton? In other words:
* Does the singleton lives from the moment where is is created (the
first call to newInstance()) till the end of your application (no need
to release it)?
* Or should it disappear before the end of the application (the related
memory should be released)?

If the answer is No, and this is my feeling, just forget about it. When
your application will end, the system will get back its memory
automatically.

If for any reason the answer is Yes, then add a member method to your
class ('deleteInstance' for example) that will:
* delete the singleton 'delete singleton;'
* set the singleton to NULL: 'singleton = NULL;' (by the way, your can
forget about 'instanceFlag' and test only on 'singleton' value: NULL
means allocate, Not NULL, don't allocate)

And call this method at the moment where you like to release the memory
linked to the singleton.

Nota Bena: don't mix allocate/free with new/delete. They are completely
different and doesn't like each other.

Have a nice evening.

Younes


On Thu, 2007-09-27 at 08:09 -0700, Chris Miller wrote:
> On 9/27/07, Laura Lozano <lau...@gm...> wrote:
> > Hello,
> >
> > I have a question about the next implementation of the singleton patter, if
> > I don't do "delete sc1" in main, is there a memory leak?  the problem is
> > that if I do in the destructor "delete single"  it produces an infinite
> > loop.
> 
> I'm not speaking from experience, but just thinking aloud.
> 
> You don't need to call delete in the destructor.  Remember, a class is
> literally just a bunch of locations in memory.  If the destructor has
> been called, delete has already been called (externally to the
> destructor) as well.  IIRC, it's your job to free all pointers to
> locations in memory that are handled by the class in the destructor,
> since those won't be freed automatically by delete.
> 
> > How could I free the memory associated to the variable single?
> 
> Perhaps use free(single)?  I'm not sure, I know there are consequences
> to mixing new/delete and malloc/free, but from my (rather limited)
> knowledge I know that free() will just release memory back to the
> system.
> 
> > Thank you.
> >
> > class Singleton
> > {
> >
> private:
> >  static bool instanceFlag;
> >  static Singleton *single;
> >  Singleton()
> >  {
> >
> //private constructor
> >  }
> > public:
> >  static Singleton* getInstance();
> >  void method();
> >  ~Singleton()
> >  {
> >  instanceFlag = false;
> >  }
> > };
> >
> > bool Singleton::instanceFlag = false;
> > Singleton* Singleton::single = NULL;
> > Singleton* Singleton::getInstance()
> > {
> >  if(! instanceFlag)
> >  {
> >  single = new Singleton();
> >  instanceFlag =
> true;
> >  return single;
> >  }
> >  else
> >  {
> >  return single;
> >  }
> > }
> >
> >
> void Singleton::method()
> > {
> >  cout << "Method of the singleton class" << endl;
> > }
> >
> > int main()
> > {
> >  Singleton *sc1;
> >  sc1 = Singleton::getInstance();
> >  sc1->method();
> >
> >  return 0;
> > }
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > TO UNSUBSCRIBE:
> > http://www23.brinkster.com/noicys/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
> >
> 
> 
-- 
Younes

Re: [Dev-C++] singleton pattern implementation.

[Chris M. <lor...@gm...>]

On 9/27/07, Younes Ouadi <ou...@ei...> wrote:
> Hello,
>
> The question to ask: is there a need to release the memory reserved for
> the singleton? In other words:
> * Does the singleton lives from the moment where is is created (the
> first call to newInstance()) till the end of your application (no need
> to release it)?
> * Or should it disappear before the end of the application (the related
> memory should be released)?
>
> If the answer is No, and this is my feeling, just forget about it. When
> your application will end, the system will get back its memory
> automatically.

What planet are you living on?  Can I move there?

> If for any reason the answer is Yes, then add a member method to your
> class ('deleteInstance' for example) that will:
> * delete the singleton 'delete singleton;'
> * set the singleton to NULL: 'singleton = NULL;' (by the way, your can
> forget about 'instanceFlag' and test only on 'singleton' value: NULL
> means allocate, Not NULL, don't allocate)
>
> And call this method at the moment where you like to release the memory
> linked to the singleton.
>
> Nota Bena: don't mix allocate/free with new/delete. They are completely
> different and doesn't like each other.

There are some collisions between them, yes.

-- 
Registered Linux Addict #431495
If You Know What's Good For You, You'll Install Linux
John 3:16!

Re: [Dev-C++] singleton pattern implementation.

[Per W. <pw...@ia...>]

Only embedded-system operating systems should/may be unable to reclaim all
memory after a program/task has ended.

However, there are other issues with not calling an object destructor. The
object may contain other resources that are not reclaimable by the OS. For
example, the object may use temporary files that should be removed by the
destructor. Or the object could control aspects of some hardware.

/pwm

On Thu, 27 Sep 2007, Chris Miller wrote:

> On 9/27/07, Younes Ouadi <ou...@ei...> wrote:
> > Hello,
> >
> > The question to ask: is there a need to release the memory reserved for
> > the singleton? In other words:
> > * Does the singleton lives from the moment where is is created (the
> > first call to newInstance()) till the end of your application (no need
> > to release it)?
> > * Or should it disappear before the end of the application (the related
> > memory should be released)?
> >
> > If the answer is No, and this is my feeling, just forget about it. When
> > your application will end, the system will get back its memory
> > automatically.
>
> What planet are you living on?  Can I move there?
>
> > If for any reason the answer is Yes, then add a member method to your
> > class ('deleteInstance' for example) that will:
> > * delete the singleton 'delete singleton;'
> > * set the singleton to NULL: 'singleton = NULL;' (by the way, your can
> > forget about 'instanceFlag' and test only on 'singleton' value: NULL
> > means allocate, Not NULL, don't allocate)
> >
> > And call this method at the moment where you like to release the memory
> > linked to the singleton.
> >
> > Nota Bena: don't mix allocate/free with new/delete. They are completely
> > different and doesn't like each other.
>
> There are some collisions between them, yes.
>
> --
> Registered Linux Addict #431495
> If You Know What's Good For You, You'll Install Linux
> John 3:16!
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: [Dev-C++] singleton pattern implementation.

[Chris M. <lor...@gm...>]

On 9/27/07, Per Westermark <pw...@ia...> wrote:
> Only embedded-system operating systems should/may be unable to reclaim all
> memory after a program/task has ended.
>
> However, there are other issues with not calling an object destructor. The
> object may contain other resources that are not reclaimable by the OS. For
> example, the object may use temporary files that should be removed by the
> destructor. Or the object could control aspects of some hardware.

I've always been told to never trust anything to clean up your memory
for you.  It'll probably leave me to clean up a lot of memory when I
don't need to, but learning how to deal with memory, with particular
regards to scope and when things come in and out of scope, will never
hurt IMHO.

-- 
Registered Linux Addict #431495
If You Know What's Good For You, You'll Install Linux
John 3:16!

Re: [Dev-C++] singleton pattern implementation.

[Chris M. <lor...@gm...>]

On 9/28/07, Younes Ouadi <ou...@em...> wrote:
> On Thu, 2007-09-27 at 20:42 -0700, Chris Miller wrote:
> > On 9/27/07, Per Westermark <pw...@ia...> wrote:
> > I've always been told to never trust anything to clean up your memory
> > for you.  It'll probably leave me to clean up a lot of memory when I
> > don't need to, but learning how to deal with memory, with particular
> > regards to scope and when things come in and out of scope, will never
> > hurt IMHO.
> >
> Chris,
>
> We are talking here about something basic: modern OS (UNIX, Linux,
> Windows ...) insures getting back memory allocated to a process once
> this process is over.
>
> Don't confuse this fact with the fact that memory leak is one of the
> issues that C and C++ developers should take seriously. Memory leak is
> the fact that a process allocates memory dynamically and left it behind
> without releasing it and this while the process is still running. This
> means that while the process is still running, it takes memory from the
> OS and waste it.

Understood.

> However, once the process is over, modern OS take back this memory. This
> is not the case of Embedded OS since these later do not enjoy the same
> conditions like the non Embedded OS.

Makes sense.

> Now, let me highlight the issue mentioned by /pwm. There are some
> resources that the OS cannot get back or cannot get back easily. Let us
> mention here:
> * a process that creates a temporary file and, by design, this process
> should delete this file before it ends. If this process doesn't do so,
> the OS cannot do it in its place. And here come up the importance of the
> concept of destructor. It can be used by a given application to release
> this kind of resources since the compiler insures calling a class
> destructor while releasing objects of this class
> * a process that opens a socket should close it properly before it ends.
> Otherwise, it will stay in the OS for a while before that this later
> release it which is not a good behavior of the process.

Okay.

-- 
Registered Linux Addict #431495
If You Know What's Good For You, You'll Install Linux
John 3:16!