{"id":5103,"date":"2016-12-26T18:03:50","date_gmt":"2016-12-26T18:03:50","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/garbage-collectio-no-thanks\/"},"modified":"2023-06-26T12:29:46","modified_gmt":"2023-06-26T12:29:46","slug":"garbage-collectio-no-thanks","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/garbage-collectio-no-thanks\/","title":{"rendered":"Garbage Collection – No Thanks"},"content":{"rendered":"

C++ is old-fashioned. C++ has no garbage collection. No garbage collection? Right! Old fashioned? Wrong!<\/p>\n

<\/p>\n

What is against garbage collection in C++? At first, garbage collection breaks one of the key principles of C++: “Don’t pay for something you don’t use.” That means if you don’t need garbage collection your C++ runtime should not waste its time cleaning up the whole garbage. My second point is more sophisticated.<\/p>\n

We have RAII in C++ and therefore the deterministic destruction of objects. But, what is RAII? That’s the topic of this post.<\/p>\n

R<\/strong>esource A<\/strong>cquisition I<\/strong>s I<\/strong>nitialization<\/h2>\n

RAII stand for R<\/strong>esource A<\/strong>cquisition I<\/strong>s I<\/strong>nitialization. Probably, the most important idiom in C++ says that a resource should be acquired in the constructor of the object and released in the destructor of the object. The key is that the destructor will be automatically called if the object goes out of scope. If this is not totally deterministic? In Java or Python (__del__<\/span>) you have a destructor but not the guarantee. Therefore, it can end disastrous, if you use the destructor to release a critical resource like a lock. That’s a classical anti-pattern for a deadlock. But in C++, we are on the safe side.<\/p>\n

The example shows the totally deterministic behavior of RAII in C++.<\/p>\n

<\/p>\n

\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38\r\n39\r\n40\r\n41\r\n42\r\n43\r\n44\r\n45\r\n46<\/pre>\n<\/td>\n
\n
\/\/ raii.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <new><\/span>\r\n#include <string><\/span>\r\n\r\nclass<\/span> ResourceGuard<\/span>{\r\n  private:\r\n    const<\/span> std::string resource;\r\n  public:\r\n    ResourceGuard(const<\/span> std::string& res):resource(res){\r\n      std::cout << \"Acquire the \"<\/span> << resource << \".\"<\/span> <<  std::endl;\r\n    }\r\n    ~ResourceGuard(){\r\n      std::cout << \"Release the \"<\/span><< resource << \".\"<\/span> << std::endl;\r\n    }\r\n};\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n\r\n  ResourceGuard resGuard1{\"memoryBlock1\"<\/span>};\r\n\r\n  std::cout << \"\\nBefore local scope\"<\/span> << std::endl;\r\n  {\r\n    ResourceGuard resGuard2{\"memoryBlock2\"<\/span>};\r\n  }\r\n  std::cout << \"After local scope\"<\/span> << std::endl;\r\n  \r\n  std::cout << std::endl;\r\n\r\n  \r\n  std::cout << \"\\nBefore try-catch block\"<\/span> << std::endl;\r\n  try{\r\n      ResourceGuard resGuard3{\"memoryBlock3\"<\/span>};\r\n      throw<\/span> std::bad_alloc();\r\n  }   \r\n  catch<\/span> (std::bad_alloc& e){\r\n      std::cout << e.what();\r\n  }\r\n  std::cout << \"\\nAfter try-catch block\"<\/span> << std::endl;\r\n  \r\n  std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
ResourceGuard<\/span> is a guard that managed its resource. In this case, the resource is a simple string. ResourceGuard<\/span> creates in its constructor (line 11 – 13) the resource and releases the resource in its destructor (line 14 – 16). It does its job very reliable.<\/p>\n
The destructor of resGuard1<\/span> (line 23) will be exactly called at the end of the main<\/span> function (line 46). The lifetime of resGuard2<\/span> (line 27) already ends in line 28. Therefore, the destructor will automatically be executed. Even the throwing of an exception does not alter the reliability of resGuard3<\/span> (line 36). Its destructor will be called at the end of the try<\/span> block (line 35 – 38).<\/p>\n
The screenshot displays the lifetime of the objects.<\/p>\n
\"raii\"<\/p>\n
I will refer once more to the program raii.cpp.<\/span> What is the key idea of the RAII idiom? The lifetime of a resource will be bound to the lifetime of a local variable. C++ automatically manages the lifetime of locals.<\/strong><\/p>\n
The idea is quite simple but has far-reaching consequences. Critical resources are bound to local objects. The remaining job is done by the C++ runtime.<\/p>\n
RAII everywhere<\/h3>\n
RAII everywhere holds for locks  std::lock_guard, std::unique_lock, <\/a>and std::shared_lock<\/a>  that manage their resource mutex. RAII everywhere holds for the smart pointers std::unique_ptr<\/a>, std::shared_ptr<\/a>, and std::weak_ptr <\/a>that manage their resource memory.<\/p>\n
Thanks to RAII we have in C++ a kind of garbage collection.<\/p>\n
But there is a subtle difference to a general garbage collection.<\/p>\n
    \n
  1. You have to explicitly use smart pointers in C++<\/li>\n
  2. The memory management with  std::unique_ptr<\/span> has by design no overhead in performance or memory compared to a raw pointer (see Memory and Performance Overhead of Smart Pointers<\/a>).<\/li>\n<\/ol>\n
    Therefore, C++ adheres to its key principle in a twofold way: Don’t pay for something you don’t use.<\/p>\n<\/p>\n
    Special resources<\/h2>\n
    Thanks to RAII, the destructor of the local object and therefore the cleaning up of the resource will be done totally deterministic. So far, so good. If the destructor can throw an exception, the destructor of the object modeling RAII will trigger the exception. This will be the case if the resource is a file. The close<\/span> function can trigger an exception. Therefore, you have to answer the question for yourself, if it’s ok, that the destructor can throw an exception. If not, you should not use RAII.<\/p>\n
    Dealing with throwing destructors (Udo Steinbach<\/strong>)<\/h3>\n
    Udo Steinbach wrote an e-mail to me about the issue with potentially throwing destructors. Here is the e-mail.<\/p>\n
    RAII is a nice thing \u2212 as long as no error can occur while destroying the object. The latter is forgotten when talking about RAII. Why a destructor should not throw, you can read in many places: https:\/\/www.qwant.com\/?q=should%20destructors%20throw<\/a>. As a result, RAII has to be supplemented manually in many cases and so it seems to be done twice.<\/p>\n
     <\/p>\n
    <\/p>\n
    \n
    class<\/span> MyFileHandle<\/span>\r\n{  public<\/span>:\r\n      MyFileHandle(...)\r\n         :handle(::OpenFile(...))\r\n      {  if<\/span> (handle == nullptr)\r\n            throw<\/span> ...;\r\n      }\r\n      ~MyFileHandle() noexcept\r\n      {  ::CloseFile(handle);\r\n      }\r\n   private:\r\n      MySystemHandle handle;\r\n};\r\n\r\n\r\n{\r\n   MyFileHandle file(...);\r\n   ...\r\n}

    <\/pre>\n<\/div>\n
    Does CloseFile() not close, the call looks correct but the handle is lost, the user has to restart the program and search and delete the file himself, or other embarrassing symptoms as they are familiar from programs.<\/p>\n
    So the class must have a throwing<\/p>\n
    void Close();<\/span><\/pre>\n
    and the destructor has to check:<\/p>\n
    { 
      MyFileHandle file(...)
      <\/span>... 
      file.Close();
    }<\/pre>\n
    This doesn’t look like pure RAII. For symmetry we need a manual Open():<\/p>\n
    {
      MyFileHandle file;
      file.Open(...); 
      ...
    <\/span>  file.Close();
    }<\/pre>\n
     <\/p>\n
    \u2212 RAII is lost. For the lover remains the consolation, that the object is now reusable and runs correctly in both non-error and error cases.<\/p>\n
    Under the condition of proper error handling from the perspective of the program user, I renounce RAII in many of my classes. Automatic tests according to an idea from boost<\/a> show<\/p>\n