Standardize Usage / Interface for raw and smart pointer usage

[IanTheEngineer]

Right now pointers are both raw and shared. We should choose one (preferably shared) and stick with it. Additionally, we should consistently return shared pointers rather than passing them in by reference and populating them.

[MatthewPeterKelly]

There are a few cases of interest here. In both cases I suggest that we follow the google style guide for C++.

1. Reference arguments: google style guide: reference arguments

• function inputs are either pass by value of const reference
• function outputs are passed by raw pointer

2. Object lifetime management: google style guide: smart pointers

• keep ownership local if possible
• if ownership is transfered, make it explicit by using unique_ptr
• case unique_ptr to shared_ptr only if absolutely necessary (prefer to move the unique_ptr)

3. Follow Resource Acquisition Is Initialization (RAII)

• avoid design patterns that require init() to be called on an object in order for it to "work"
• use a factory method to return a unique pointer to the object. If the constructor failed then the unique pointer is null.

[IanTheEngineer]

I agree with 2 and 3. However, on reading google's doc on reference arguments, I don't see a good justification for function outputs being passed by raw pointer. Who is responsible for cleaning up the object?

[MatthewPeterKelly]

I believe that the caller is responsible for managing the object lifetime. This method of handling output arguments is also suggested by the ROS style guide.

If the function is creating an object with a non-trivial lifetime, then we should return a unique pointer to the object.