Destructor Order
-
Just a question about good practice. Is it reasonable to rely upon the order of destruction of a group of objects within another object? Especially in regard to exception safety and readablity. Specifically. I'm using CComPtr's to attempt to make some of my DirectShow code as exception safe as possible. I've realized that just releasing the interfaces that occurs in the CComPtr's destructors aren't enough if an exception is thrown, and that the whole filter graph needs to be torn down first. I'm going to put the tear down operation in an another class, and instantiate it on the stack, but I need the destructor of that object to be called before all of the CComPtr's destructors are called. I ?think? destructor order is controlled by declaration order, but in general is relying upon that fact good practice? Any help would be appreciated. :) Andrew
-
Just a question about good practice. Is it reasonable to rely upon the order of destruction of a group of objects within another object? Especially in regard to exception safety and readablity. Specifically. I'm using CComPtr's to attempt to make some of my DirectShow code as exception safe as possible. I've realized that just releasing the interfaces that occurs in the CComPtr's destructors aren't enough if an exception is thrown, and that the whole filter graph needs to be torn down first. I'm going to put the tear down operation in an another class, and instantiate it on the stack, but I need the destructor of that object to be called before all of the CComPtr's destructors are called. I ?think? destructor order is controlled by declaration order, but in general is relying upon that fact good practice? Any help would be appreciated. :) Andrew
walker_andrew_b wrote: I ?think? destructor order is controlled by declaration order, but in general is relying upon that fact good practice? It's specified by the language so it's probably not unreasonable :-) Not everyone knows that so if your code absolutely relies upon it, a comment to that effect is probably in order.
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
-
Just a question about good practice. Is it reasonable to rely upon the order of destruction of a group of objects within another object? Especially in regard to exception safety and readablity. Specifically. I'm using CComPtr's to attempt to make some of my DirectShow code as exception safe as possible. I've realized that just releasing the interfaces that occurs in the CComPtr's destructors aren't enough if an exception is thrown, and that the whole filter graph needs to be torn down first. I'm going to put the tear down operation in an another class, and instantiate it on the stack, but I need the destructor of that object to be called before all of the CComPtr's destructors are called. I ?think? destructor order is controlled by declaration order, but in general is relying upon that fact good practice? Any help would be appreciated. :) Andrew
walker_andrew_b wrote: I ?think? destructor order is controlled by declaration order, Yes, it is. More specifically, order of creation (just in case you're using pointers to allocate memory dynamically). walker_andrew_b wrote: is relying upon that fact good practice? It's smart, but how will you remember that two weeks from now. If the workaround is difficult, use this by all means, but COMMENT IT!
Vikram. ----------------------------- 1. Don't ask unnecessary questions. You know what I mean? 2. Avoid redundancy at all costs. 3. Avoid redundancy at all costs. "Do not give redundant error messages again and again." - A classmate of mine, while giving a class talk on error detection in compiler design. -
walker_andrew_b wrote: I ?think? destructor order is controlled by declaration order, Yes, it is. More specifically, order of creation (just in case you're using pointers to allocate memory dynamically). walker_andrew_b wrote: is relying upon that fact good practice? It's smart, but how will you remember that two weeks from now. If the workaround is difficult, use this by all means, but COMMENT IT!
Vikram. ----------------------------- 1. Don't ask unnecessary questions. You know what I mean? 2. Avoid redundancy at all costs. 3. Avoid redundancy at all costs. "Do not give redundant error messages again and again." - A classmate of mine, while giving a class talk on error detection in compiler design.Vikram Punathambekar wrote: It's smart, but how will you remember that two weeks from now. If the workaround is difficult, use this by all means, but COMMENT IT! Well, it's written, or at least a big part of it is. The whole reason I headed down this path was to make sure that the classes were exception safe. I've been looking into the Herb Sutter's material (Exceptional C++), and this way seems to be the only way to make any kind of exception safety guarantee. I never realised how much extra work it was going to be, nor the compromises that would have to be made. Doing proper exception handling is so hard :(( Thanks for the feedback though :)