move away from raw pointer to smart pointers

Get answers to all your basic programming questions. No Ogre questions, please!
Post Reply
iblues1976
Gnome
Posts: 379
Joined: Fri Sep 16, 2011 4:54 pm
x 10

move away from raw pointer to smart pointers

Post by iblues1976 »

Hello,
I have been searching here is Ogre Forums about this. I wonder with the amount of people working with OGRE and the few developing Ogre3D 1.x the new Ogre3D 2.0+, I wanted to ask this question.

In the case when a pointer is needed, which maybe a few instances, with C++11 and shared_ptr and unique_ptr, is it worth moving from using raw pointers to smart pointers.

What is your take on this based on your experience?
Thanks
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: move away from raw pointer to smart pointers

Post by Klaim »

It all depends on your intention. Basically, you need a general policy. If you always use smart pointers (or other RAII based tools) to manage resource (like heap allocated objects) then you can assume that all raw pointers are not owning the pointed data. All owning pointers then should be obvious (either shared or unique or whatever is used) or encapsulated into some wrapper.
I've been using that way of doing for some years now and find it effective (the code is far more obvious and it don't change performance). I also use pools and special accessors to manipulate the objects in the pool.

Note that Ogre's source code is not at all an example of this way of thinking as it's more recent than Ogre.
In the case when a pointer is needed, which maybe a few instances, with C++11 and shared_ptr and unique_ptr, is it worth moving from using raw pointers to smart pointers.
To be short:
- if the pointer own the pointee, use a smart pointer OR encapsulate the whole in a type using RAII which would only manage that pointer;
- if the owning pointer should be the sole owner of the object, use unique_ptr;
- if several pointers will be owning the pointeee in the same time, use shared_ptr;
- if the pointer don't own the pointee, use a raw pointer;

Here owning mean "the one responsible for releasing the resource".
As said, this work well only if all your code base follow these rules because then you know that all raw pointers are only refering the the pointee and should never be deleted. If you start changing policy on the meaning of your pointers in the middle of a project, you will only lose clarity as some parts will follow a way of thinking and other parts will follow others.

Also, avoid new and delete in general (but in particular when using smart pointers), use make_shared/make_unique (make_unique is C++14 but have been added to VS2013 and all other compilers so...). Of course you can't avoid it when implementing some memory management tools (like a pool), but that should be localized, isolated and rare (used by the rest of the code which will then avoid memory manipulations itself).
iblues1976
Gnome
Posts: 379
Joined: Fri Sep 16, 2011 4:54 pm
x 10

Re: move away from raw pointer to smart pointers

Post by iblues1976 »

Thanks Klaim for your post... it is very detailed...

if you can (I will search online later), could you provide links to read further about the following

A) encapsulate the whole in a type using RAII which would only manage that pointer;

B) Of course you can't avoid it when implementing some memory management tools (like a pool), but that should be localized, isolated and rare (used by the rest of the code which will then avoid memory manipulations itself).
thanks
Post Reply