Using a global STL vector

[timmay3141]

I need to use a global vector in a program, and I was wondering - will the vector automatically de-allocate the memory when the program exits? I ask because I'm using OpenGL and GLUT, so after the window is closed, you don't get a chance to empty the vector in main() (because glutMainLoop() never returns). I could still empty the vector using the atexit() function, but I was wondering if this is really necessary or if it will happen automatically.

 

[palbano]

>> will the vector automatically de-allocate the memory when the program exits?

The vector during destruction will free all memory associated with handling the vectors memory. This would not include any heap based allocations you made and stored the pointers in the vector.

But since the progam is exiting, why does it matter since all memory will be released anyway?

-pete

 

[Cagliostro]

After program exit you could forget about memory leaks inside that rograms, because it is an entirely destroyed by Operation System process. Each program(process) in the system owns 4Gb of virtual memory and has its virtual registry. All space where program runs is virtual. All memory allocations/deallocations inside program are in private virtual memory of the program. You should care about MemoryLeaks only while program is running. This memory is also destroyed.

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[PerFnurt]

I don't think exiting the application is an exuse to not deallocate properly.

The most obvious reason: If you dont deallocate everything, "unintentional" memoryleaks gets obscured.
The same way you're likely to miss an important compilation warning if the compliation normally spits out a lot of warnings.

Another reason:Code should be designed to be modifiable. And if I decide to move a collection from the global scope to a local I'd want to do it with a minimum of effort.

Just my $0.2


/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[Cagliostro]

sometimes, deallocation of memory is much more expensive than simply exit. For example when paged memory is too fragmented. Memory will be always deallocated completely on Win95 and Higher versions of OS. Also files used as paged memory are aleays deleted by OS. There are no obscurities because they are virtual and exist as much as exist process.

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[PerFnurt]

>sometimes, deallocation of memory is much more expensive than simply exit
Good point. That could be problem if exiting the application is time critical. Finding errors and searching for memory leaks may also be expensive, and its really matter of how you set your priorities. For me, as a programmer, code-quality and bug detection/prevention is the top prio.

But of course I cant be too stubborn. If the exiting takes unreasonable (=it is a problem) long time due to deallocing and I can't solve that by restructuring the logic, then I guess I would skip the final deallocations. But (and this is my point) it would be a last resort and not something I'd do by default.

>There are no obscurities because they are virtual and exist as much as exist process

Im not sure I understand what you mean, but this is what I meant by &quot;obscuring&quot;:

1) I assume we agree on that there are situations where you infact should deallocate (not necessarily talking about when exiting the application).

2) Should such deallocation not be executed I would like to be able to see that ASAP

3) If my application normally reports a whole bunch of memory leaks, chanches are high that I won't spot the above mentioned missing deallocation. Ie it is &quot;obscured&quot; as it is just one tree in a forest of reported memory leaks.


/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[ArkM]

Let's remember C++ Standard: global (i.e. external static) entity constructor automatically invokes BEFORE main started (after mem alloc) and destructor acts AFTER program die, then any C++ processor MUST do 'destructing' and deallocation for all globals. What else can we do with true global var in post-mortem atexit? All done. It doesn't matter virtual or not memory installed: it's language rule and C++ implementors troubles...

 

[Cagliostro]

>AFTER program die
BEFORE program begin die

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[ArkM]

Yes, after main function die, not a program. Thank you.

 

[SLUDGE2]

Destruct all data at program exit. If you had a pointer to a Vector, for argument's sake, it would not be destructed. This may be fine, but what of the objects that it contains? The objects it contains could utilize the destructor for persistence, writing their state to the disk.

In this case, not destructing upon exit is an error with real world consequences.

 

[chipperMDW]

class Foo
{
  public:
    ~Foo() { /* die */ }
};

vector<Foo> foos;
vector<Foo*> ptrs;

int main()
{
    Foo f;
    Foo* p = new Foo;

    foos.push_back( f );
    ptrs.push_back( p );
}

// the destructor for f is called

// the destructor for p (just a pointer) is called
// the destructor for the Foo p points to is NOT called

If you want the Foo p points to the be destroyed, do this:

1)
Go to

http://www.boost.org

and get the Smart Pointers library (or use Loki or any other smart pointer library).

2)

vector<smart_ptr<Foo> > sptrs;

int main()
{
    smart_ptr<Foo> sp = new Foo;

    sptrs.push_back( sp );
}

// sp's destructor is called, which in turn calls
// the destructor of the Foo it points to.

 

[PerFnurt]

chipperMDW :
Is using smart_prt combined with collections really safe? I mean, if you access the element, wouldn't the ownership be transferred, as its done with auto_ptr?



/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[chipperMDW]

auto_ptr isn't safe because, as you say, it transfers ownership when you &quot;copy&quot; it.

Boost's shared_ptr is reference-counted, so the last one out shuts off the lights (the last shared_ptr to be pointing to a specific object destroys it). It is safe with collections.

I think the requirements for something to be used safely in a vector (or collection in general) are copy semantics (so not auto_ptr) and less-than-comparability.

So I guess a more accurate piece of advice would be to use a smart pointer with copy semantics and less than comparability (and anything else I missed).

 

[PerFnurt]

>It is safe with collections
Ok. Cool.

>and less-than-comparability.
That's for tree implmentations (like map and set). Not needed fo vector or list.





/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[chipperMDW]

> That's for tree implmentations (like map and set). Not needed fo vector or list.

Yeah, you're right. I was thinking vector had a built-in sort for some reason.

So smart pointers with at least copy semantics = safe with vector.

 

[timmay3141]

I've been away for a while, that's why I haven't been responding. However, your responses have more than answered my question. Thanks everyone.