Explicit indication of shared_ptr in naming convention

[htuch]

Can we switch to the following convention:

typedef std::unique_ptr<Foo> FooPtr;
typedef std::shared_ptr<Bar> BarSharedPtr;

across the code base? I'm finding it hard to review code with shared_ptr hidden under BarPtr (and read in general), as the shared ownership semantics are hidden.

If this sounds acceptable, I'm very happy to do an immediate PR to clean this up and document in the coding conventions.

@jamessynge @mattklein123

[mattklein123]

Sure that's fine with me.

[htuch]

Also will add Const to names to propagate this where needed, e.g. replace typedef std::shared_ptr<const Instance> InstancePtr; with typedef std::shared_ptr<const Instance> InstanceConstSharedPtr;.

[jamessynge]

FWIW, I'd prefer just std::shared_ptr instead of having FooPtr, because then it becomes easy to tell the difference between bare pointers, shared_ptr and unique_ptr.

[htuch]

I think we have no ambiguity if we never use Ptr for raw pointers, use Ptr for unique pointers, Shared Ptr for shared and appropriate const modifiers in there. I can see the attraction of using type aliases, It's a little more compact without the visual noise of the std:: <>. That said, I don't mind either way, @mattklein123's call :)

[mattklein123]

@htuch @jamessynge at this point I don't really care that much either, but I agree the current situation is confusing. I think the typedefs do make the code more readable, but it's going to be a bit harder to maintain consistency. If consensus is to kill the typedefs I don't have a problem with it. Perhaps we should poll a few other people.

[htuch]

Sure, let's continue this Monday when folks are around.

[htuch]

@RomanDzhabarov

[RomanDzhabarov]

My preference would be FooSharedPtr for brevity and consistency with FooPtr for std::unique_ptr