3 ms·
> I didn't realize that a delegating constructor counted as "fully initializing" the object. The main constructor is, I imagine, just treated as some "extra cod
by imron 3y ago
> I didn't realize that a delegating constructor counted as "fully initializing" the object. The main constructor is, I imagine, just treated as some "extra code that is run after the real ctor"?
This does not appear to be the case. The code in question is not calling the constructor that throws! It's still calling
int main(){S s;}
If you change it to:
int main(){S s(42);}
It will throw and not call the destructor (both latest clang and gcc).
See for example https://godbolt.org/z/ohjchhGvz https://godbolt.org/z/ohjchhGvz
- turtledragonfly 3y agoAh, thanks for that follow-up. That is more in line with my mental model. So... seems like a bad example in the article (:
- imron 3y ago> That is more in line with my mental model. Right, mine too. It wasn't until I saw your comment that I thought to go and verify how it worked.
- delta_p_delta_x 3y agoTo be precise, with proper exception handling, the former will throw, but the destructor will also be called as part of the stack-unwind.
- imron 3y agoI'm not sure I understand. The former 'int main(){S s;}' is just calling the default constructor which doesn't throw. Only the latter 'int main(){S s(42);}' throws, and it will never call the destructor. Or maybe I've misunderstood? Perhaps modify the code example I linked to on godbolt to show what you mean?
- delta_p_delta_x 3y agoMy bad, I swapped 'former' and 'latter'. What I simply meant is this: https://godbolt.org/z/Y7W6GenbE https://godbolt.org/z/Y7W6GenbE If an exception is properly handled (i.e. inside a try-catch block), the destructor of any object that might be destroyed after leaving said scope, is called as part of the stack-unwind, guaranteed by the specification.