{"id":110783,"date":"2025-01-20T07:00:00","date_gmt":"2025-01-20T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110783"},"modified":"2025-01-20T15:42:33","modified_gmt":"2025-01-20T23:42:33","slug":"20250120-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20250120-00\/?p=110783","title":{"rendered":"Reminder: When a C++ object fails to construct, the destructor does not run"},"content":{"rendered":"

In C++, if an object’s constructor fails (due to an exception), destructors are run for the object’s member variables and base classes, but not for the object itself. The principle at play is that you cannot destruct something that was never constructed in the first place.<\/p>\n

Consider this pull request<\/a>:<\/p>\n

com_timeout_t(DWORD timeoutInMilliseconds)\r\n    : m_threadId(GetCurrentThreadId())\r\n{\r\n    m_cancelEnablementResult = CoEnableCallCancellation(nullptr);\r\n    err_policy::HResult(m_cancelEnablementResult);\r\n    if (SUCCEEDED(m_cancelEnablementResult))\r\n    {\r\n        m_timer.reset(CreateThreadpoolTimer(\r\n            &com_timeout_t::timer_callback, this, nullptr));\r\n        err_policy::LastErrorIfFalse(\r\n            static_cast<bool>(m_timer));\r\n        if (m_timer)\r\n        {\r\n            FILETIME ft = filetime::get_system_time();\r\n            ft = filetime::add(ft, filetime::\r\n                    convert_msec_to_100ns(timeoutInMilliseconds));\r\n            SetThreadpoolTimer(m_timer.get(), &ft,\r\n                    timeoutInMilliseconds, 0);\r\n        }\r\n    }\r\n}\r\n\r\n~com_timeout_t()\r\n{\r\n    m_timer.reset();\r\n\r\n    if (SUCCEEDED(m_cancelEnablementResult))\r\n    {\r\n        CoDisableCallCancellation(nullptr);\r\n    }\r\n}\r\n\r\n\u27e6 member variables: \u27e7\r\n\r\nHRESULT m_cancelEnablementResult{};\r\nDWORD m_threadId{};\r\nbool m_timedOut{};\r\nwil::unique_threadpool_timer_nocancel m_timer;\r\n<\/pre>\n
The idea is that the constructor first calls Co\u00adEnable\u00adCall\u00adCancellation<\/code> and reports the failure via err_policy::HResult()<\/code>. In the WIL library, the err_policy<\/code> defines how the caller wants errors to be reported.<\/p>\n\n\n\n\n\n
 <\/td>\nerr_returncode_policy<\/tt><\/td>\nerr_exception_policy<\/tt><\/td>\nerr_failfast_policy<\/tt><\/td>\n<\/tr>\n
HResult(hr)<\/tt> with failure<\/td>\nreturn hr;<\/tt><\/td>\nThrow an exception<\/td>\nTerminate the process<\/td>\n<\/tr>\n
LastErrorIfFalse(false)<\/tt><\/td>\nreturn GetLastError();<\/tt><\/td>\nThrow an exception<\/td>\nTerminate the process<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
When writing code in WIL, you pass each result to the error policy so that it can report the error in the manner the caller requested.<\/p>\n
The code saves the result of Co\u00adEnable\u00adCall\u00adCancellation<\/code> in m_cancel\u00adEnablement\u00adResult<\/code> so that it knows whether it needs to call Co\u00adDisable\u00adCall\u00adCancellation<\/code> at destruction to balance it out.<\/p>\n
The tricky case here is if Co\u00adEnable\u00adCall\u00adCancellation<\/code> succeeds, but Create\u00adThreadpool\u00adTimer<\/code> fails. If the error policy is err_exception_policy<\/code>, this throws an exception out of the constructor, which bypasses the destructor<\/i>. This means that the Co\u00adDisable\u00adCall\u00adCancellation<\/code> never occurs, and we leak a call cancellation.<\/p>\n
If we want to clean up things that were done in the constructor, we have to ask a member variable or base class to clean it up for us.<\/p>\n
In this case, one solution is to  use the wil::unique_call<\/code> to call a function at destruction<\/a>.<\/p>\n
namespace details                              <\/span>\r\n{                                              <\/span>\r\n    inline void CoDisableCallCancellationNull()<\/span>\r\n    {                                          <\/span>\r\n        ::CoDisableCallCancellation(nullptr);  <\/span>\r\n    }                                          <\/span>\r\n} \/\/ namespace details\r\n\r\ncom_timeout_t(DWORD timeoutInMilliseconds)\r\n    : m_threadId(GetCurrentThreadId())\r\n{\r\n    const HRESULT cancelEnablementResult = CoEnableCallCancellation(nullptr);\r\n    err_policy::HResult(cancelEnablementResult);\r\n    if (SUCCEEDED(cancelEnablementResult))\r\n    {\r\n        m_ensureDisable.activate();<\/span>\r\n        m_timer.reset(CreateThreadpoolTimer(\r\n            &com_timeout_t::timer_callback, this, nullptr));\r\n        err_policy::LastErrorIfFalse(\r\n            static_cast<bool>(m_timer));\r\n        if (m_timer)\r\n        {\r\n            FILETIME ft = filetime::get_system_time();\r\n            ft = filetime::add(ft, filetime::\r\n                    convert_msec_to_100ns(timeoutInMilliseconds));\r\n            SetThreadpoolTimer(m_timer.get(), &ft,\r\n                    timeoutInMilliseconds, 0);\r\n        }\r\n    }\r\n}\r\n\r\n\/\/ ~com_timeout_t()<\/span>\r\n\/\/ {<\/span>\r\n\/\/     m_timer.reset();<\/span>\r\n\/\/\r\n\/\/     if (SUCCEEDED(m_cancelEnablementResult))<\/span>\r\n\/\/     {<\/span>\r\n\/\/         CoDisableCallCancellation(nullptr);<\/span>\r\n\/\/     }<\/span>\r\n\/\/ }<\/span>\r\n\r\n\u27e6 member variables: \u27e7\r\n\r\nwil::unique_call<decltype(&details::CoDisableCallCancellationNull),          <\/span>\r\n            details::CoDisableCallCancellationNull, false> m_ensureDisable{};<\/span>\r\nDWORD m_threadId{};\r\nbool m_timedOut{};\r\nwil::unique_threadpool_timer_nocancel m_timer;\r\n<\/pre>\n
The wil::unique_call<\/code> calls the function described by its first two template parameters\u00b9 at destruction. The third template parameter (default true<\/code>) specifies whether the object should be initially active. You can put the object into the active state by calling activate()<\/code>, thereby enabling the call at destruction.<\/p>\n
We want to call Co\u00adDisable\u00adCall\u00adCancellation<\/code> only if the Co\u00adEnable\u00adCall\u00adCancellation<\/code> succeeded, so our unique_call<\/code> is initially inactive.<\/p>\n
Now, if there is an exception at construction, the member object m_ensure\u00adDisable<\/code> will destruct and call Co\u00adDisable\u00adCall\u00adCancellation<\/code> if necessary.<\/p>\n
Bonus chatter<\/b>: Note that for err_exception_policy<\/code> and err_failfastpolicy<\/code>, a failure to enable call cancellation prevents the constructor from running to completion, which means that the corresponding destructor always<\/i> disables call cancellation. This means that the internal bool<\/code> inside the unique_call<\/code> is always true<\/code>, yet we consume data space for it and code space to check it.<\/p>\n
If we wanted to optimize further by avoiding the extra bool<\/code> and the code to test it, we could use a different helper class depending on the error policy.<\/p>\n
template<typename err_policy>\r\nstruct WithCallCancellation\r\n{\r\n    WithCallCancellation()\r\n    {\r\n        err_policy::HResult(CoEnableCallCancellation(nullptr));\r\n    }\r\n\r\n    WithCallCancellation(const WithCallCancellation&) :\r\n        WithCallCancellation() { }\r\n\r\n    ~WithCallCancellation()\r\n    {\r\n        CoDisableCallCancellation(nullptr);\r\n    }\r\n\r\n    constexpr bool active() { return true; }\r\n};\r\n\r\ntemplate<>\r\nstruct WithCallCancellation<err_returncode_policy>\r\n{\r\n    WithCallCancellation() :\r\n        m_active(SUCCEEDED(\r\n                CoEnableCallCancellation(nullptr))) {}\r\n\r\n    WithCallCancellation(const WithCallCancellation&) :\r\n        WithCallCancellation() { }\r\n\r\n    ~WithCallCancellation()\r\n    {\r\n        if (m_active) {\r\n            CoDisableCallCancellation(nullptr);\r\n        }\r\n    }\r\n\r\nprotected:\r\n    bool active() { return m_active; }\r\n    const bool m_active;\r\n}\r\n\r\n\r\ntemplate<typename err_policy>\r\ncom_timeout_t : private WithCallCancellation<err_policy><\/span>\r\n{\r\n    com_timeout_t(DWORD timeoutInMilliseconds)\r\n        : m_threadId(GetCurrentThreadId())\r\n    {\r\n        if (this->WithCallCancellation::active())<\/span>\r\n        {\r\n            m_timer.reset(CreateThreadpoolTimer(\r\n                &com_timeout_t::timer_callback, this, nullptr));\r\n            \u27e6 etc \u27e7\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
The idea here is to take advantage of the empty base optimization (EBO) so that in the case where the error policy is not err_returncode_policy<\/code>, we don’t waste space keeping track of something we know will always be true.\u00b2<\/p>\n
This solution is probably overkill for com_timeout_t<\/code>, which is a class that is expected to have a short lifetime, and certainly not expected to have thousands of instances.<\/p>\n
\u00b9 WIL was written when C++11 was the new hotness. If it were written today, we would use template<auto><\/code> to collapse the two parameters into one.<\/p>\n
Bonus bonus chatter<\/b>: Another option would be to reorder the operations so that Co\u00adEnable\u00adCall\u00adCancellation<\/code> is done last. That way, if the call fails, the m_timer<\/code>‘s destructor will clean up the timer. This is quicker, but it is also more fragile because somebody might add more initialization to the constructor later without realizing that the Co\u00adEnable\u00adCall\u00adCancellation<\/code> must come last because we don’t have a member or base class to clean it up for us.<\/p>\n
Bonus bonus bonus chatter<\/b>: Removing the destructor from com_timeout_t<\/code> activates the default move constructor and move assignment operator, but we don’t want that because the timer callback has already captured the this<\/code> pointer. As part of removing the constructor, the second PR also explicitly deletes the copy constructor and copy assignment operator (which in turn suppress the move constructor and move assignment operator).<\/p>\n
If you need to run after a failed construction, you have to put it in a base class or member variable.<\/p>\n","protected":false},"author":1069,"featured_media":110434,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-110783","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
If you need to run after a failed construction, you have to put it in a base class or member variable.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110783","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=110783"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110783\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/110434"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=110783"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110783"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110783"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\u00b2 If you can assume C++20, then you can make it a member variable with [[no_unique_address]]<\/code>. But note  special treatment for the Microsoft Visual C++ compiler<\/a> due to the ABI-breaking nature of [[no_unique_address]]<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"