Dynamic storage duration

[Adrian]

Is it defined in the standard what happend to dynamic storage that has
not been deleted at program termination?

I read through the Dynamic storage section and cannot find it.


Adrian

 

[Rolf Magnus]

Is it defined in the standard what happend to dynamic storage that has
not been deleted at program termination?

I read through the Dynamic storage section and cannot find it.

The C++ standard doesn't say anthing about what happens after the program
exits.

 

[Adrian]

The C++ standard doesn't say anthing about what happens after the program
exits.

Probably explains why I cannot find it

For example though the C standard says that it closes all open files.
Is there anything that happens with new'ed objects? Or is this all
implementation defined.

 

[Ron Natalie]

Probably explains why I cannot find it

For example though the C standard says that it closes all open files.
Is there anything that happens with new'ed objects? Or is this all
implementation defined.

They don't get destructed if that is what you are asking. Now what
happens to the memory? Same as with malloc'd memory in C. It's
not specified. In practice systems nearly always reclaim all the
allocated memory upon exit. However, if your code allocates other
resources inside the object that the destructor is supposed to clean
up, it won't happen.

 

[Adrian]

They don't get destructed if that is what you are asking. Now what
happens to the memory? Same as with malloc'd memory in C. It's
not specified. In practice systems nearly always reclaim all the
allocated memory upon exit. However, if your code allocates other
resources inside the object that the destructor is supposed to clean
up, it won't happen.

I wanted a gurantee on the freeing of memory. Guess it isnt so and I
will cleanup after myself.

As long as I stay away from STL containers is there any problem with a
singleton implementation that uses a auto_ptr to hold the private
implementation as a static?

ie
class AImpl
{
};

class B
{
private:
static std::auto_ptr<AImpl> impl_;
}

That should be deleted properly on exit?


Adrian

 

[Doug]

Probably explains why I cannot find it

For example though the C standard says that it closes all open files.
Is there anything that happens with new'ed objects? Or is this all
implementation defined.

Hiya Adrian,

It's all platform dependent.

A modern operating system with virtual memory management (like Linux
or Windows) will release memory (and many other types of resources)
when the process terminates. For the memory, it's pretty much just
throwing away the page tables and any backing store used when paging.

An older (or modern embedded!) operating system without VMM might not
do this, though. And of course, any other resources (like shared
memory segments or mutexes) might not be released cleanly, if at all.

So for portable code, always try to clean up the mess you make. If
it's a play project on your home PC, don't waste your time unless you
need to learn - do it a few times.

Doug

 

[Adrian]

It's all platform dependent.

This is commerical code that will be ported at a later date. So I need
to make sure that it is compliant to the standard.

So for portable code, always try to clean up the mess you make. If
it's a play project on your home PC, don't waste your time unless you
need to learn - do it a few times.

Is there any reason a static auto_ptr would not clean up correctly?
Instance of the object is not dependent on anything else..

I know about the gotcha's with auto_ptr's and containers but was
wondering if I missed any?

 

[Doug]

Is there any reason a static auto_ptr would not clean up correctly?
Instance of the object is not dependent on anything else..

Hi Adrian,

I think a static would be cleaned up, but I'm not absolutely sure
w.r.t. the standard. Someone here more knowledgable can tell us
that. I hope...

This wee program:

#include <iostream>
using namespace std;

class MX
{
public:
MX() { cout << "ctor" << endl; }
~MX() { cout << "~ctor" << endl; }
};

static auto_ptr<MX> gMX(new MX());

int main(void)
{
return 0;
}

.... produces ...

[ds@boxa tmp]# gcc test.cpp -lstdc++
[ds@boxa tmp]# ./a.out
ctor
~ctor

.... on my old linux box. I imagine a static class member var would
also be cleaned up, but I'm off to bed now.

Doug

 

[Rolf Magnus]

I wanted a gurantee on the freeing of memory. Guess it isnt so and I
will cleanup after myself.

Well, if you want a guarantee, you might find it with your OS. However, as
Ron already wrote, even if the memory is reclaimed, destructors of the
dynamic objects aren't called.

As long as I stay away from STL containers is there any problem with a
singleton implementation that uses a auto_ptr to hold the private
implementation as a static?

You might run into something similar to the problem mentioned in
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14 .

 

[Adrian]

You might run into something similar to the problem mentioned inhttp://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14.

Checking the FAQ I dont think I will. Below is a trivial example of
what I am actually doing.

#include <iostream>
#include <memory>

class Impl;

class pImpl
{
private:
friend class Impl;
friend class std::auto_ptr<pImpl>;
pImpl() {};
~pImpl() {};
pImpl(const pImpl &);
pImpl &operator=(const pImpl &);

void print_some_stuff() { std::cout << "Hi\n"; };
};

class Impl
{
public:
Impl()
{
if(_pimpl.get()==0)
{
std::auto_ptr<pImpl> temp(new pImpl);
_pimpl=temp;
}
};

void print_some_stuff() { _pimpl->print_some_stuff(); };
private:
Impl(const Impl &);
Impl &operator=(const Impl &);
static std::auto_ptr<pImpl> _pimpl;
};

std::auto_ptr<pImpl> Impl::_pimpl;

void foo();
void bar();

int main(int argc, char *argv[])
{
foo();
Impl().print_some_stuff();
bar();

return 0;
}


void foo()
{
Impl().print_some_stuff();
}

void bar()
{
foo();
Impl().print_some_stuff();
}