Smart Pointers

[1337]

Yes, the mysterious topic finally made it to the forum! So many rumors...

I mainly want to open this discussion here to decide about the naming conventions. The rest is so "on-the-fly" that the one implementing it has to find the right ways.

Now, what do you suggest? I haven't exactly worked with smart pointers a lot and therefore I'm not familiar with any naming conventions. A smart pointed object type could be called for instance SOrxonoxClass. But that doesn't fit very well for classes beginning with an S ^^

[x3n]

Hm, good question. Another idea would be to use the prefix "c" for all classes (cSpaceShip) and then use the original name for the smart pointer. But I think we have to implement it first and then see where and how the smart pointers are used. Only then we'll see what naming convention is the least confusing I think.

[beni]

Do we really need another class for each existing class? should work with templates, right?

[x3n]

Yeah, but there's often a short and simple typedef to the (long) template name

[1337]

The complete expression would be boost::shared_ptr<Scene>, which adds quite a lot of code. So by typedefing every class in the Prereqs file we can achieve code that is much better readable.

[beni]

of course that makes sense. I don't know that much about various approaches to solve that problem, so I didn't know that this'll be clear and we're really only talk about names here. Great I figured that out now .

Why use c? Don't see the point in that...

I checked out the Internet and found following examples:

• OrxonoxClassType
• ptrOrxonoxClass
• spOrxonoxClass
• OrxonoxClassPtr
• OrxonoxClass_p

I like the three in the middle.

[1337]

I think it would be wise to let the reader know that it is a pointer. I suppose we'll be using shared_ptr and weak_ptr from boost (as suggested in this ticket).
And I agreed that we don't yet really know how often the weak_ptr has be used, so no name for that yet. But shared_ptr sure will be. And my favourite is OrxnoxClassPtr.

[greenman]

i too like OrxonoxClassPtr.
but if we also have to use weak ptrs then maybe ptrOrxonoxClass (shared) and wptrOrxonoxClass (weak) would be a better choice ?

[beni]

and what about OrxonoxClassWPtr? or is this not as readable? hmm, maybe not . Or maybe OrxonoxClassPtrW or something similar...

It's all a matter of what you prefer and what is easier to read. In the end we use the smart pointers to lessen the errors we could make (among other reasons of course). That's why we should increase the error probability to use unreadable or easy to misread-able names.

[1337]

I suppose the weak pointer will have little, but very important, use.

[beni]

So we shouldn't change out preferred OrxonoxClassPtr just because of that.

I suggest OrxonoxClassPtrW for clear and consistent naming.

[1337]

If you want consistency:
OrxonoxClassSPtr (shared_ptr)
OrxonoxClassWPtr (weak_ptr)

but I think omitting the 'S' is perfectly ok.

So, enough of this discussion, we can wrap it up later one when the naming comes up. But I'm always happy to let people discuss naming matters.

[x3n]

Personally I wouldn't mind if we just use a template name, but with a typedef for the smart pointer classes (no boost:: and maybe shorter). Because it's somehow a mistery if you have to append "Ptr" to get the right type.

And whatever option we chose, I really insist to make the difference between shared and weak pointers obvious (and yes, this means more than just an additional "W").

Don't understand this as a proposal, just to show in which direction this post aims:
Ptr<OrxonoxClass>
WeakPtr<OrxonoxClass>

[1337]

I actually quite agree. Frankly I thought you'd be the one to make it less obvious , herefore please apologise my prejudice.
Now, the long versions really are too much to write, but a Ptr<> is just 5 letters more and I'm perfectly happy with it because (as you've pointed out) people will notice that's a template and might even ask why (and maybe figure out what a smart pointer really is;)).

[beni]

You guys are right. Naming it with just an additional "Ptr" increases confusion as it looks exactly like a class name. Writing those <> is a pain in the ass, but at the end of the day it is maybe the clearest proposal.