{"id":1905,"date":"2020-03-04T09:23:54","date_gmt":"2020-03-04T03:53:54","guid":{"rendered":"https:\/\/www.rangakrish.com\/?p=1905"},"modified":"2020-03-04T09:31:34","modified_gmt":"2020-03-04T04:01:34","slug":"deleted-destructor-in-c","status":"publish","type":"post","link":"https:\/\/www.rangakrish.com\/index.php\/2020\/03\/04\/deleted-destructor-in-c\/","title":{"rendered":"Deleted Destructor in C++"},"content":{"rendered":"

Since C++ 11<\/strong><\/em>, we can use the keyword delete<\/strong><\/em> to declare functions as deleted and thus prohibit the use of these functions in the code. See this article<\/strong><\/em><\/a>\u00a0for a brief overview.<\/p>\n

In particular, the destructor<\/strong><\/em> of a class\/struct\/union can be declared as deleted<\/strong><\/em>. In today\u2019s article, I am going to discuss this specific feature in detail with several examples.<\/p>\n

It is useful to recall the basic principle of object creation in C++: When an object of a user-defined type is created, an appropriate constructor<\/strong><\/em> is automatically called, and when the object goes out of life, its destructor<\/strong><\/em> is automatically called (see this<\/strong><\/em><\/a>\u00a0for the complete destructor semantics). Automatically<\/strong><\/em>, here, means that the compiler generates code behind the scenes to make sure these events happen without explicit intervention<\/strong><\/em> by the programmer.<\/p>\n

The following code fragment illustrates this idea:<\/p>\n

\"Example-1\"<\/a>
Example-1<\/strong><\/figcaption><\/figure>\n

If the programmer does not define a destructor explicitly, then the destructor is implicitly defined by the compiler. This can be suppressed by using = delete<\/strong><\/em> in the destructor declaration:<\/p>\n

\"Deleted<\/a>
Deleted Destructor<\/strong><\/figcaption><\/figure>\n

What effect does this have on the code? Look at the following example.<\/p>\n

\"Example-2\"<\/a>
Example-2<\/strong><\/figcaption><\/figure>\n

Statements numbered (1), (3) and (5) are OK only if a valid destructor is present, and since the destructor is deleted<\/strong><\/em> in this case, the compiler generates error messages as expected.<\/p>\n

What the above example also shows is that we can only create objects of class A<\/strong><\/em> on the heap<\/strong><\/em>, but then we cannot delete<\/strong><\/em> such an object. That is, of course, not a good practice because it will lead to memory leaks. What can we do in such situations?\u00a0<\/span><\/p>\n

What if we use the smart pointer unique_ptr<\/strong><\/em><\/a>\u00a0to manage our object?\u00a0<\/span><\/p>\n

\"Example-3\"<\/a>
Example-3<\/strong><\/figcaption><\/figure>\n

Unfortunately, this does not solve our problem, because when the unique_ptr<\/strong><\/em> object goes out of scope, it (by default) applies delete<\/strong><\/em> on the managed object, leading to a call of the destructor, and thus triggering the compiler error!<\/p>\n

Fortunately, there is a way to address this problem. unique_ptr<\/strong><\/em> allows us to supply a custom deleter<\/strong><\/em>, which will be called when the object goes out of scope. Therefore, we define a (static) method in our class and pass a pointer to this function to the unique_ptr<\/strong><\/em> instance, along with our pointer.<\/p>\n

\"Example-4\"<\/a>
Example-4<\/strong><\/figcaption><\/figure>\n

This time we do not get any error because our destructor is not called. But it is very important to note that the responsibility for releasing the memory associated with our A<\/strong><\/em> object (obtained through new<\/strong><\/em> operator) rests with A::Deleter()<\/strong><\/em> function. Failure to handle this correctly will lead to runtime problems.<\/p>\n

Effect on Inheritance<\/h3>\n

So far, we have considered different cases where the class with deleted destructor<\/strong><\/em> is used directly. What would happen if another class, say B<\/strong><\/em>, is derived from A<\/strong><\/em>?<\/p>\n

When a class is designed to act as a base class in a hierarchy, its destructor is usually virtual<\/strong><\/em> (see this article<\/strong><\/em><\/a>). In accordance with this guideline, let us declare A::~A()<\/strong><\/em> as virtual<\/strong><\/em> and deleted<\/strong><\/em>. See what happens in this case.<\/p>\n

\"Example-5\"<\/a>
Example-5<\/strong><\/figcaption><\/figure>\n

The program does not compile. My Visual Studio 2019 (ver 16.4.5)<\/strong><\/em> gives the following errors:<\/p>\n

\"Example-5<\/a>
Example-5 Compiler Errors<\/strong><\/figcaption><\/figure>\n

Could it be because A::~A()<\/strong><\/em> is virtual<\/strong><\/em>? Let us see what happens if we remove the virtual<\/strong><\/em> keyword:<\/p>\n

\"Example-6\"<\/a>
Example-6<\/strong><\/figcaption><\/figure>\n

Unfortunately, even this does not go through. Here are the errors:<\/p>\n

\"Example-6<\/a>
Example-6 Compiler Errors<\/strong><\/figcaption><\/figure>\n

From the above two examples (and variants of these examples), we can conclude that it is impossible to meaningfully derive any class from a class with deleted destructor<\/strong><\/em>.<\/p>\n

Let us consider the other possibility where a class with deleted destructor is derived from a normal base class.\u00a0<\/span><\/p>\n

\"Example-7\"<\/a>
Example-7<\/strong><\/figcaption><\/figure>\n

We get an error when we compile this code (notice we have not instantiated Y<\/strong> <\/em>at all):<\/p>\n

\"Example-7<\/a>
Example-7 Compiler Errors<\/strong><\/figcaption><\/figure>\n

Since the base destructor is virtual, destructors of all derived classes are virtual, and according to the language, it is not OK to delete<\/strong><\/em> an overriding<\/strong><\/em> virtual destructor. Hence the error. What if the base class destructor is not virtual?<\/p>\n

\"Example-8\"<\/a>
Example-8<\/strong><\/figcaption><\/figure>\n

The above is similar to Example-2<\/strong><\/em>, except for lines 18 and 19. While it is fine for a base class pointer to point to a derived class, it is not correct to delete the derived object through the base pointer when the base destructor is not virtual. This can cause undefined behaviour.<\/p>\n

Effect on Composition<\/h3>\n

The next case we will consider is one where an object of a class with deleted destructor, is a member of another class<\/strong><\/em>. Look at the following code.<\/p>\n

\"Example-9\"<\/a>
Example-9<\/strong><\/figcaption><\/figure>\n

In the above example, the struct Compose<\/strong><\/em> contains a data member of type A.<\/strong><\/em> As expected, we get errors when we compile this code:<\/p>\n

\"Example-9<\/a>
Example-9 Compiler Errors<\/strong><\/figcaption><\/figure>\n

So, what do you think of deleted destructor<\/strong><\/em>? Should we use it? My general view is that if the situation warrants it, is up to the programmer to use any feature the language supports. After all, if deleting a destructor is never correct, then the language could have forbidden it. Having said that, I wish to add that a deleted destructor is probably quite rare in real world projects. I personally consider a private (or protected) destructor<\/strong><\/em> as a meaningful alternative to deleted destructor<\/strong><\/em>. \u00a0<\/span><\/p>\n

Hope you found today\u2019s discussion informative. You can download the example programs from here<\/strong><\/em><\/a>.<\/p>\n

Have a great day!<\/p>\n","protected":false},"excerpt":{"rendered":"

Since C++ 11, we can use the keyword delete to declare functions as deleted and thus prohibit the use of these functions in the code. See this article\u00a0for a brief overview. In particular, the destructor of a class\/struct\/union can be declared as deleted. In today\u2019s article, I am going to discuss this specific feature in […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"jetpack_seo_schema_type":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[49],"tags":[67,230],"class_list":["post-1905","post","type-post","status-publish","format-standard","hentry","category-c","tag-c","tag-destructor"],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9OLnF-uJ","jetpack-related-posts":[{"id":1928,"url":"https:\/\/www.rangakrish.com\/index.php\/2020\/03\/15\/stdis_destructible\/","url_meta":{"origin":1905,"position":0},"title":"std::is_destructible","author":"admin","date":"March 15, 2020","format":false,"excerpt":"In the last article, I explained the deleted destructor in some detail. Today, I would like to talk about a related construct, a type trait called std::is_destructible. Type traits, defined in the header , are a big help when it comes to implementing template metaprogramming. \u00a0See this\u00a0article for a nice\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Private\/Protected Destructor","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/03\/Example7.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/03\/Example7.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/03\/Example7.jpg?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":2011,"url":"https:\/\/www.rangakrish.com\/index.php\/2020\/06\/06\/stdis_trivial\/","url_meta":{"origin":1905,"position":1},"title":"std::is_trivial","author":"admin","date":"June 6, 2020","format":false,"excerpt":"Today let us try to understand the type trait std::is_trivial. This trait checks if the given type is a trivial type. For a precise definition of what trivial means, please visit the official page. As usual, we will go through three cases: - Primitive types - Classes without inheritance -\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Program Output","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/06\/output2.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":2024,"url":"https:\/\/www.rangakrish.com\/index.php\/2020\/06\/21\/stdis_standard_layout\/","url_meta":{"origin":1905,"position":2},"title":"std::is_standard_layout","author":"admin","date":"June 21, 2020","format":false,"excerpt":"In our last post, we learnt about the type trait std::is_trivial. Today, let us go through another type trait that is quite similar. The expression\u00a0is_standard_layout::value returns true if the layout of objects of type T is compiler independent, and hence is of standard format. Else, it returns false. This is\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"The Difference","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/06\/Example4.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/06\/Example4.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/06\/Example4.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/06\/Example4.jpg?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":3691,"url":"https:\/\/www.rangakrish.com\/index.php\/2025\/05\/04\/beyond-ownership-understanding-the-role-of-stdweak_ptr-in-modern-c\/","url_meta":{"origin":1905,"position":3},"title":"Beyond Ownership: Understanding the Role of std::weak_ptr in Modern C++","author":"admin","date":"May 4, 2025","format":false,"excerpt":"Smart Pointers in C++ are elegant abstractions for managing dynamic memory safely, avoiding dangling pointers and preventing leaks. While std::unique_ptr and std::shared_ptr are well understood and widely used, std::weak_ptr often demands a deeper dive to use correctly. In this article, I will attempt to explain what it is and where\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Circular Reference Example","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2025\/05\/code1-300x289.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":700,"url":"https:\/\/www.rangakrish.com\/index.php\/2017\/11\/21\/c17-stdoptional\/","url_meta":{"origin":1905,"position":4},"title":"C++17: std::optional","author":"admin","date":"November 21, 2017","format":false,"excerpt":"Suppose we want to write a function that returns a value, but with the possibility that\u00a0 the computation might fail. This failure can be represented as an exception, or as a return value that unamibiguously denotes failure (for example, -1). Throwing an exception is a strong form of failure and\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Example1","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2017\/11\/Example1-3.png?resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2017\/11\/Example1-3.png?resize=350%2C200 1x, https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2017\/11\/Example1-3.png?resize=525%2C300 1.5x"},"classes":[]},{"id":1091,"url":"https:\/\/www.rangakrish.com\/index.php\/2018\/10\/14\/c17-stdapply-and-stdinvoke\/","url_meta":{"origin":1905,"position":5},"title":"C++17 – std::apply() and std::invoke()","author":"admin","date":"October 14, 2018","format":false,"excerpt":"Calling a function (or function object) dynamically, through a pointer known at runtime, is a common programming scenario. Almost all languages support this use case. Lisp, for example, has apply and funcall. When using apply, you can see that the arguments are passed via a separate list object. With funcall,\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Calling Member Functions","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2018\/10\/Code5.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2018\/10\/Code5.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2018\/10\/Code5.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2018\/10\/Code5.png?resize=700%2C400&ssl=1 2x"},"classes":[]}],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/posts\/1905","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/comments?post=1905"}],"version-history":[{"count":0,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/posts\/1905\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/media?parent=1905"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/categories?post=1905"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/tags?post=1905"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}