I've been sick; I'm running about +3F.First time I do understand what you say.
'BodyPart(std::unique_ptr<Texture>, float, float);'So what type should BodyPart's constructor accept?
This signature forces the client to use a specific method of creation.
Because 'BodyPart' assumes ownership of the texture created by the client source, you may store the texture however you like.And what type should it store among its members?
A method returning a 'weak_ptr' is truly fine, but that limits your storage options to 'shared_ptr'. Also, once I have a 'weak_ptr' I can create a 'shared_ptr' so a texture living beyond the 'BodyPart' object would still be a concern.So what type should BodyPart return then, if this was possible?
I'd probably just return a reference. (I don't care for the absurdity of complicating a design solely because the simple approach isn't "OOP" enough.)
There is nothing wrong with what you've done; I just don't like it. Technically, it limits feature options a bit, but then I don't know that 'GluePoint' isn't final.So what type should GluePoint::Connect accept, and possibly what type should it store to make a connection like this possible?
I'd probably just use a 'weak_ptr<GluePoint>' and give the associated 'shared_ptr<?>' a "null deleter" for such local objects.
Soma