On 4/27/2011 4:18 AM, Stewart, Robert wrote:
I think until the naming noise settles, you'd be better off not renaming your class, updating the documentation, or sending messages with yet another name in the subject line. You've gone through, what, ten iterations now?
Yup.
I found your rationale.html, so I now understand that you manage a counter to track when your pointers refer to blocks of memory and not, in order to know when to release memory. Apparently, there are two reference counts then. The first is in the smart pointer to know a datum is unreferenced and the other to know when no data in what you term a "set" is being referenced. What's a bit confusing is that you depict three pointers referring to one "set" which has a count of just one. Presumably, this is because you use some non-portable technique to determine stack versus free store allocation so that only stack-based allocations modify the "set" count.
The technique comes down to a call to is_from() which will tell whether a pointer is part of a pool or not. It turns out if the return value is false then its behavior is undefined because apparently comparing two pointers not part of the same array will cause undefined behavior. This can be discussed and I would like knowing more about any platforms this can cause any problem because I am under the impression there is place for improvement in the C++ standards regarding this issue.
Assuming I have understood your design reasonably correctly, then the "block allocation" mechanism is the unique feature and suggests the name "block_ptr."
block_ptr... I never thought of that but thanks I'll rename it once more.
BTW, s/instanciate/instantiate/ and s/subdivise/subdivide/ in your docs.
No problem. Thanks, -Phil