Boost logo

Boost :

Subject: Re: [boost] [Memory Managed Pointer] Review Request
From: Phil Bouchard (philippe_at_[hidden])
Date: 2011-04-27 12:03:06

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?


> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at