-1

Recently I came accross a class containing a private unique pointer member variable. In the constructer it was initialized with make_unique and in the destructer it was cleared with reset. I know that make_unique performs a heap allocation. Is there any reason for this overhead ? Why not use a "normal" member variable.

Werner
  • 281
  • 1
  • 12
  • 5
    I recommend posting the class. – synchronizer Mar 19 '18 at 22:22
  • 3
    Calling `reset` explicitly in the destructor, seems at first glance to be a horrible and unnecessary thing to do, so I'm not sure I would assume there is a reason. – Nir Friedman Mar 19 '18 at 22:23
  • Related: [Is the pImpl idiom really used in practice?](https://stackoverflow.com/questions/8972588/is-the-pimpl-idiom-really-used-in-practice) – anatolyg Mar 19 '18 at 22:25
  • There is zero overhead for a `unique_ptr`. No need to manually reset it in the destructor though. – Galik Mar 19 '18 at 22:33
  • Best we can do without seeing the code in question is make guesses. It is possible that the writer of the code did everything exactly right. It's also possible they write C++ code like a drunken monkey taught Java programming by someone trained only in Fortran. – user4581301 Mar 19 '18 at 22:33
  • 1
    Without providing more information this question is either too broad, or unclear imo. – Galik Mar 19 '18 at 22:36
  • 1
    For your last question: https://stackoverflow.com/questions/22146094/why-should-i-use-a-pointer-rather-than-the-object-itself – Tas Mar 19 '18 at 22:36

2 Answers2

5

There's a few valid reasons to make a unique_ptr member variable of a class. Without seeing the class I can't say which, if any apply; as I wrote in the comment calling reset explicitly in the destructor seems pretty awful so I don't think I would give the author the benefit of the doubt.

Here are some of the reasons I can think of:

  1. The object in question is runtime polymorphic. That is, you have a unique_ptr<Base> and you could actually be pointing to a Derived.
  2. You want your class to be movable, but the member in question is immovable, or "sucks" to move for some reason. This comes up a lot with std::mutex; it's very awkward as a memeber variable. In 17, immovable objects can be returned from functions so they aren't as bad. But in 14 or prior, immovable objects are just really irritating. So your object can hold a unique_ptr<mutex> instead and still be movable. Variants of this are types that are expensive to move (structs with tons of members) or don't obey proper exception safety guarantees (but this is very rarely valid IMHO).
  3. You really want to reclaim the memory associated with the type. I've seen this too, sometimes you are doing tons of complex config during initialization, that later you don't need. If you have a unique_ptr<InitInfo> or something like that you can call reset so that once your program is up and running in the long running perf critical part, you've returned a lot of memory.

A bad but common reason to use unique_ptr is to defer initialization, i.e. you need to construct a member later than the object as a whole gets constructed. This is bad in general but even if you need to do this, you can do it with optional.

Nir Friedman
  • 17,108
  • 2
  • 44
  • 72
1

and in the destructer it was cleared with reset.

This is redundant. The implicitly generated destructor would have been sufficient.

Is there any reason for this overhead ?

Possibly. Not necessarily. Depends on why dynamic allocation was used.

Why not use a "normal" member variable.

There can be reasons. It's impossible to tell those reasons with no hints about the definition, or usage of the class.

eerorika
  • 232,697
  • 12
  • 197
  • 326