sharedPTR
Use boost shared pointers
Not only does this make good sense, since we are using shared pointers, but there is a good reason for it.
SOME protocols do not provide slave->master acknowledges. Therefore, one would have to be implemented as a "modelling artefact", simply to allow the owner of the shared pointer to free it.
Using boost's shared pointers, a reference count is kept in the "smart" pointer ever time it is used. This means that the shared pointer can be passed around the system, when it is no longer being used, it will fall out of scope and be "freed".
For a protocol that passes acknowledgement information back to the master, the shared pointer will be passed all the way back to the master, before the master will allow it to "fall from scope". In the case of a one way communication, the shared pointer will be allowed to fall out of scope in the slave.
Cost
The cost of this is one extra increment and checked decrement each time the shared pointer is "copied" or falls from scope.
In the case of protocols that do not require a response, this cost is probably the same as the cost of sending back a "fake" acknowledge. In all other cases, this is, we believe, an insignificant cost.
Convenience layer, or interoperability layer
Ideally this should be in the convenience layer - the convenience layer should choose how best to make sure that there are no memory leaks etc. However, if the pointer being passed is a smart pointer, then this needs to be known at the interoperability layer....
Posted January 8th, 2008 by MarkBurton