1

So smart pointers are nothing but classes that wrap a raw pointer, only the object contains a destructor that calls delete

if that's exact is there any reason to use traditional raw pointers? is it always more convenient to use smart pointers?

2 Answers2

2

Smart pointers are one form of resource management. There are others which may be more appropriate. For example, for a memory-only graph of objects (i.e., none of the objects hold a non-memory resource of any form) using allocations into an arena and letting go of the arena is more effective: it has much smaller overhead and is substantially faster to release, especially if the objects are not necessarily hot in cache. The object graphs maintained within the arena is linked using raw pointers.

Smart pointers are one of many tools for resource management. They tend to be overused by people unaware of other tools. Of course, that is a common pattern: to thee who only wield a hammer everythings looks like a nail!

Dietmar Kühl
  • 150,225
  • 13
  • 225
  • 380
1

Smart pointers come with a certain overhead. If you don't need the functionality a smart pointer offers (automatic memory management through RAII) then just stick to using raw pointers. Remember, raw pointers themselves are not necessarily bad, raw pointers that own resources are. Ownership requires explicit delete-ion. We don't want that.

Hatted Rooster
  • 35,759
  • 6
  • 62
  • 122
  • 1
    @Downvoter Can I get a comment why? – Hatted Rooster Dec 17 '16 at 22:01
  • 1
    std::unique_ptr is specifically designed to be zero-overhead. Granted that's the only smart pointer with that property. But smart pointer overhead is just what you would have to write yourself to have the smart pointer's behaviour. – rubenvb Dec 17 '16 at 22:02
  • 1
    @rubenvb Yet default initializing a `unique_ptr` does more than default initializing a plain pointer. – juanchopanza Dec 17 '16 at 22:05
  • 1
    @juanchopanza if default-initialization is the overhead you worry about, you're doing something wrong. – rubenvb Dec 17 '16 at 22:09
  • 1
    @rubenvb How would you even know that? Do you know all the possible applications in the world? Do you really think there is no context in which this could matter? If so, maybe propose that default initialization of built ins be changed to result in zero initialization. – juanchopanza Dec 17 '16 at 22:12
  • 3
    @runenvb: the smart pointer model assumes that you'll actually destroy objects. The language specification implicitly allows garbage collection strategies effectively allowing to "let go" of objects which are not referenced again, reusing the memory they occupied (there is no need to do actual garbage collection as an allocation arena can be used instead). Not destroying objects is a signifificant win in some situations. The smart pointer strategy, even using `std::unique_ptr`, does result in an overhead an alternative strategy does not have. – Dietmar Kühl Dec 17 '16 at 22:17
  • 1
    @juan the fact that there is a unique_ptr owning pointer implies there will be memory allocated near where the pointer variable is created. So allocate the memory at the point of pointer variable creation. I'm willing to learn though, so please enlighten me of cases not related to archaic C library interfaces. – rubenvb Dec 17 '16 at 22:24
  • 1
    @dietmar Is there any implementation (and example of usage in some project I can read the source of) of c++ language level garbage collection? I thought it was just a footnote in the Standard... – rubenvb Dec 17 '16 at 22:25
  • 1
    @rubenvb: there is mandated language in the standard (3.8 [basic.life] paragraph 5) which states, effectively, that memory not referenced otherwise can be reused without objects being destroyed. Aside from the Boehm garbage collector I know there is at least a debugging collector (it is a commercial product). However, even without actual garbage collectors objects can be allocated from a suitable allocator which can just make all its memory available when objects are no longer used. I have used this strategy with great results in some projects whose code is, however, not publicly available. – Dietmar Kühl Dec 17 '16 at 22:43
  • @rubenvb Interestingly, `unique_ptr` has a default constructor. According to your reasoning this should never be used, so maybe it can be removed from the standard. – juanchopanza Dec 18 '16 at 09:12