0

According to Google C++ Style Guide - Static and Global Variables,

Decision on Destructions

...
Therefore, we only allow objects with static storage duration if they are trivially destructible.

Common Patterns

...

  • Maps, sets, and other dynamic containers: ... If you do really prefer a dynamic container from the standard library, consider using a function-local static pointer, as described below.
  • If all else fails, you can create an object dynamically and never delete it by using a function-local static pointer or reference (e.g., static const auto& impl = *new T(args...);).

As far as I know, dynamically allocated objects will never be freed.
OS will free every unfreed object when the program ends, but this isn't the correct way.
Why not deleting a dynamically allocated object is a selectable option?

김선달
  • 1,485
  • 9
  • 23
  • 5
    why Google "C++ Style Guide" work might work for their codebase, it's a poor coding style for general use. – bolov Feb 16 '21 at 08:48
  • If there is a static object that you use all through-out the program, and the object doesn't manage any resources other than memory, you may never clear it up since the OS will do the clean-up after you. That messes up tools that detect memory leaks, so I wouldn't do it personally. – Aykhan Hagverdili Feb 16 '21 at 08:48
  • Also have a look at [The C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) – Aykhan Hagverdili Feb 16 '21 at 08:51
  • It seems that keeping a naked static pointer variable and dynamically creating / deleting a corresponding object will be a conforming solution. So no problem here. – user7860670 Feb 16 '21 at 08:52
  • 1
    @AyxanHaqverdili "the OS will do the clean-up after you" The OS will only free resources, but never call the destructors. If you *need* the functionality of the destructors, you simply can't follow such style guides. Example: If you have an object which represents persistence and will write its state into a file on destruction, this style guide will simply not work. I personally have no idea what this guide helps. – Klaus Feb 16 '21 at 08:53
  • @Klaus It helps by preventing SIOF / SUOF. – user7860670 Feb 16 '21 at 08:55
  • The underlying reason for this guideline is to avoid the static initialization order fiasco. But there is also the **de**initialization order fiasco. Even a function local static may be destroyed before its last use (it happens rarely). A leaking pointer is their way to go around this. But it's not a very good way. There are other techniques, such as what the `iostream` header does. – StoryTeller - Unslander Monica Feb 16 '21 at 08:56
  • @Klaus I specifically mentioned that you can do this iff *the object doesn't manage any resources other than memory*. This is usually done when the destructor isn't doing anything critical. Then it doesn't matter. Note that I am not enforcing the rule, just explaining it. This is common enough that knowing about it is useful, even though I wouldn't do it myself, as I mentioned in the original comment. – Aykhan Hagverdili Feb 16 '21 at 08:57

1 Answers1

1

Why not deleting a dynamically allocated object is a selectable option?

Because of this:

OS will free every unfreed object when the program ends

In short, not deallocating memory is a problem because that can cause unnecessary memory use in form of memory leaks. Unnecessary use of memory doesn't matter to a program that is no longer running, so it isn't a problem in this case.

Note that if you do follow this style, then you may find that some memory analysers report the lack of deallocation as a memory leak which may be difficult to distinguish from unintentional memory leaks.

Aside from the (non-)problem of memory leak, to explain why this might be a preferable option, this style avoids some problems with Static Initialisation Order Fiasco without requiring the Nifty Counter Idiom. As an additional bonus, it likely makes the shutdown of the program a bit faster.

eerorika
  • 232,697
  • 12
  • 197
  • 326
  • 1
    "A bit faster" can also be "a lot faster". My worst case was a program that ran for six hours, 4 of which were waiting for the hard disk swapping in objects being destroyed. Leaking the objects instead meant that the OS just discarded the memory without even touching swap. Instant 4 hour saving. – MSalters Feb 16 '21 at 11:20