Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Adding feature clarity of memory management #86
Adding a non-inherited feature to an object requires doing this at the moment:
This looks like the application programmer has to memory-manage the new feature theirself. While it is possible (i.e. you can manually destruct the feature before object, but not before) and sometimes convenient, the API itself does not suggest that containingObject will destroy its features on destruction.
I would suggest adding a method
As features always require an object on construction, it would be a logical addition.
If I remember correctly, someone suggested doing similar thing also for object children, because (in terms of memory management) they are behaving the same --
I'll think that through in regards to planned "data-oriented" improvements to see if these two ideas can play well together. The ultimate goal is to get rid of naked pointers and
One potential problem came across my mind:
Although the above argument order is probably common practice (is it?), these functions would add constraints on feature and object constructors, which might be annoying in some cases.
Looking for inspiration into the STL,
Maybe it would be easier if the Feature's object was not required to be set in the constructor. I had thought that a good practise was to have the constructor should do as little as possible. But this would break the contract that a Feature always has an object.
As an example, if we ever added some kind of callbacks or hooks for when features are added/removed it would open up a world of pain whereby application code could be run (and throw exceptions from) constructors.
The alternative is requiring a sub-classed feature's constructor to conform to some kind of contract, or require an allocator interface.
I think I'd personally prefer to be able to attach Features to Objects later than construction, as with the Object parent->child relationship. It opens up the possibilities of: more flexible Feature pooling; effectively enabling/disabling features; remove logic from my own constructors.
Googling around for some precedent, maybe this would provide some inspiration:
The classes are being designed to implement an interface. Even the compiler will let people know when they have done something wrong. If someone is making such a class they have already agreed to adhere to the design pattern.