auto_ptr and object encapsulation

[Eglin]

I

[Merth]

This is how I interpreted your argument:

When an exception is thrown, stack memory is cleaned up, but heap memory is not. Pointers are on the stack, but the memory they point to is on the heap. When an exception is thrown, we have a mem leak for whatever a stack pointer was pointing to. Wrapping the pointer into a smart pointer will avoid this situation.

However, I do see some issues:
* Most of the team codes in C.
* What are the situations that would cause an exception to be thrown?
* What is the typical way to cache a wrapped pointer? (one that works on linux, so no GIT)
* With regard to auto_ptr, how would it know whether to call delete versus delete[]?

[Eglin]

Originally Posted by Merth

When an exception is thrown, stack memory is cleaned up, but heap memory is not. Pointers are on the stack, but the memory they point to is on the heap. When an exception is thrown, we have a mem leak for whatever a stack pointer was pointing to. Wrapping the pointer into a smart pointer will avoid this situation.

That is correct. However, the process of unwinding the stack upon raising exceptions includes calling the destructor for each object in any object which is destroyed. This is precisely why I think that everything should belong to something else (what is now a static global pointer to an object on the heap would then be an object on the stack, or in the case of object members which throw errors on construction a pointer that we will still be able to clean-up on destruction of the main object)... if all our global variables were wrapped inside some execution object (probably created inside each net.c, also wrapping the main execution loop), then we would always fall into this situation - rendering auto_ptrs (and global variables) pretty much useless. It would also go a long way towards resolving problems with namespace pollution.

However, I do see some issues

Yeah... there are tons. I didn't mean to indicate that I _LIKE_ auto_ptr usage or that I want to see more of it! Quite the contrary, I find that every project I have worked on that made/required use of them had serious design flaws. The autoptr clone was already existant in the code, and the previous instantiation already used it. The existing parser object was wrapped inside an auto_ptr, so it was natural for me to attempt to wrap my derived class in one, too. My class easily can throw errors on construction, though, because it depends on finding a perl interpreter that it can use, so I wanted to wrap it in a try block. It was just plain sillyness (like I said in the original post) that prevented me from noticing that the auto_ptr was scope-limited to the try block :) Not a mistake I will make again. Not really a big deal, since the parser object is intrinsic to the zone server. If the pointer is deleted before execution stops, the program will crash anyway (since there is tons of code that uses the parse object pointer w/o checking for null). Therefore, just using delete at the end of main would work just as well as the auto_ptr. Again, if there were a main execution object, the creation and deletion could just be done in that object