Printable View
Hi guys,
I was wondering if you have a class instance crash your program during initialization, does everything the constructor has done up to that point come undone? I take it that all classes created are automatically destroyed, and the same with concrete types, but what about free-store objects? Are they automatically deleted? Could a call to abort() cause a memory leak (just in case the OS didn't clean up properly)?
It is my understanding that it depends on how the class has been implemented. If the class has pointer data members whose initialization/assignment was done through free-store objects defined outside the class, you will have a memory leak. You avoid this by defining a smart pointer structure for your class, for instance. You will also have a memory leak if the class implements free-store objects inside its definition, but incorrectly manages them.
As I see it, destructors still get called on program crash. If the class manages its own pointers and its own free store objects, it will gracefully release any memory usage.
> As I see it, destructors still get called on program crash.
No, at least, if a constructor fails and you throw an exception your destructor is never called, so like you said it is better to use members that handle their own memory.
And if a constructor fails and it isn't caught, that seems to be undefined behavior: it may crash or it might not, and there is still no guarantee the destructor is called.
See also: http://www.parashift.com/c++-faq-lit....html#faq-17.2
Thanks for the help. What about a situation like this though:Say the function 'b.init()' caused the program to terminate suddenly (in a way that couldn't be caught by PossibleLeaker's constructor). Would PossibleLeaker's destructor be called/the constructor's work be undone? I don't see how it could since the object isn't even constructed yet. Could that be a memory leak?Code:class PossibleLeaker {
A *aptr;
B b;
C c;
public:
PossibleLeaker() {
A *aptr = new A;
b.init();
c.init(); // just to make it obvious that the constructor isn't finished.
}
~PossibleLeaker() {
if( aptr ) delete aptr;
}
};
> Could that be a memory leak?
I'd say it depends on how C's init() function works, and if C handles it's own possible construction problems. These kinds of things can snowball quickly, so if you at least fix Possible Leaker's class members, you greatly reduce the risk of having construction problems.
>> Would PossibleLeaker's destructor be called/the constructor's work be undone?
No. Look at FAQ number 17.4 in citizen's link.
Did you meant to write B instead of C or am I missing something? If b.init() terminates then will the constructor of PossibleLeaker not just fail before it reaches c.init()?Quote:
Originally Posted by citizen
Other than that, I think I'll just have to make do with using exceptions and report errors in a sort of global way rather than have each class handle its own (by reporting and terminating). It does seem like better style doing what you suggested, but it means I need to properly learn about exceptions before I can have my code working (C++'s learning curve may not be steep, but it doesn't seem to know where to end!).
> Did you meant to write B instead of C or am I missing something? If b.init() terminates then will the constructor of PossibleLeaker not just fail before it reaches c.init()?
No, I read that wrong. In a way it's the comment's fault really.
> C++'s learning curve may not be steep, but it doesn't seem to know where to endl;
:p A good C++ book covers exceptions and what happens in detail, but learning exceptions is easy, just read a tutorial.
I think this was discussed in detail in a guru of the week but I can't remember which.
If I recall correctly it boiled down to having to catch all the possible exceptions in your constructor, cleaning up any allocated memory in the catch block and rethrowing an exception if need be.
Or use RAII for all your member variables so that they will be cleaned up automatically if an exception is thrown from the constructor.
Do you mean using smart pointers?
As far as I know RAII (resource aquisition is initialisation) and smart pointers are not the same thing, they just work well together.
Smart pointers are one example of the use of RAII. They would help in this situation because they use RAII. Note that "resource acquisition is initialization" doesn't accurately identify the true meaning of RAII. It is more about the fact that a resource will be cleaned up automatically when the object goes out of scope. In the case of dynamically allocated memory, a smart pointer will delete the raw pointer automatically if an exception is thrown without any extra code, so if your class contains only smart pointers then no catch is necessary in the constructor to delete that memory.
The benefits of RAII in this situation are more broad than just dynamically allocated memory. For example, fstream uses RAII. If you open a file with an fstream in your constructor, and then later an exception is thrown inside that constructor, the file will be closed automatically.
Fair enough.
Although RAII does stand for resource aquisition is intialisation.
I always understood the advantage of RAII to be in the object creation stage when the object would come into existance fully working without needing further processing (and avoiding aquisition of resources early on in the code, with the intialisation a long way down, leaving an object that was not quite usable around)
It does, however Daved's point I believe was that the name alone doesn't tell the whole story.Quote:
Originally Posted by sigfriedmcwild
Well after Daved raised his point I went off and did some research.
Indeed RAII doesn't tell the whole story, the idiom would be more aptly named "resource aquisition is initialisation, release is (erk I'm missing the right word here)"
Anyway RAII is a great solution for the original poster's problem. (And I'm sure nobody will mind too much the sideline discussion abotu hte meaning of RAII)
>> Although RAII does stand for resource aquisition is intialisation.
You are correct. http://www.parashift.com/c++-faq-lit....html#faq-6.18 has some info on the confusion between the name and what it refers to (that FAQ mentions "Resource Reclamation Is Destruction" might be a better name).
Also, the entire FAQ #17 at that site has good information on the subject of RAII and exception handling.
Simple solution is never do anything but variables initialization in constructors. Don't perform dynamic memory allocation, opening files, etc, etc. Anything that has a chance of failing should not be performed inside of a constructor. Only perform operations that will succeed 100% of the time. Initializing variables of your class to constant values will always succeed.
If you absolutely must allocate a resource then use the provided try and catch mechanism and even perhaps write your own exception class and create an object of that type to handle the exception. Some exceptions are non-recoverable no matter what you do, which is why I advise not to perform any operation inside of a constructor that can throw an exception or fail.
>> Simple solution is never do anything but variables initialization in constructors. Don't perform dynamic memory allocation, opening files, etc, etc.
I completely disagree. Use the constructor to construct and fully initialize the object so that it is ready to use. That means that if your class requires dynamic memory allocation, opening a file, etc, you should absolutely do that in the constructor. Just take the precautions already discussed in this thread and in the linked FAQ (e.g. RAII).
>> Some exceptions are non-recoverable no matter what you do, which is why I advise not to perform any operation inside of a constructor that can throw an exception or fail.
This is exactly why you should perform operations that can throw or fail inside the constructor. Otherwise, you are left with an object that is uninitialized and cannot do its job. If you let it fail inside the constructor, then the user of your class doesn't have to worry about checking to see if the object has been initialized correctly or not. If the object exists, it means the constructor succeeded, which means the instance is initialized.
It might make sense to postpone initialization if you are using a lazy evaluation optimization, or if your code doesn't use exceptions and would be negatively affected by adding them. Otherwise, do all your initialization in the constructor.
We obviously won't agree here. I do not recommend this.Quote:
I completely disagree. Use the constructor to construct and fully initialize the object so that it is ready to use. That means that if your class requires dynamic memory allocation, opening a file, etc, you should absolutely do that in the constructor. Just take the precautions already discussed in this thread and in the linked FAQ (e.g. RAII).
I have never heard of somebody arguing this position. I assume you would use a separate init or open function to do the resource acquisition. If not, please clarify. Do you have any arguments for why that would be better than RAII and exceptions?
Thanks for all the help guys, it's much appreciated.
I read the bits on parashift about RAII and I'm mildly confused about the 'renaming' of the acronym. I understand what it's saying, but I thought one of the big things about RAII was that if you initialize an object on creation then you save the overhead of using the default constructor and then the copy one (which I heard was significant).
To implement RAII in my example does that just mean initialising the member objects in an initialization list in the constructor?
No, in your example you would have to replace the A* with a smart pointer. Initializing it in the initialization list is a good idea, but not necessary.
Don't worry about what RAII stands for, it's not really important. It just means that when you create an object it acquires its resources, and then it automatically cleans itself up when it is destructed.
That is why a smart pointer that holds A* would help. It is the smart pointer that uses RAII, not necessarily your class. If you replace A* with a smart pointer that calls delete automatically when it goes out of scope, then it doesn't matter if your object is destroyed normally, or if it gets destructed due to an exception from b.init(). Either way the smart pointer's destructor will be called, and delete will be called on your A*.
>> I thought one of the big things about RAII was that if you initialize an object on creation then you save the overhead of using the default constructor and then the copy one (which I heard was significant).
This is an important concept, although I don't think this is a specific benefit of RAII. Technically, a user of a class that models RAII could still violate that rule. For example, std::string uses RAII, but you can still use string's default constructor and then assign to the string later.
I agree with Daved on this one. The problem with seperate init functions is that you can forget to call them or if you use your class with a template or framework that doesn't call them you're stuffed.Quote:
Originally Posted by Daved
(I ran into this problem recently when using Boost.Statechart which uses constructors and destructors and entry and exit conditions of states)
The only time you should use an "init" function is when you want to have polymorphic initialisation behaviour, in which case you should make your constructor private and use a static Create function to create your class
http://www.parashift.com/c++-faq-lit....html#faq-23.5