On 4/24/2011 1:05 PM, Phil Bouchard wrote:

The following output: [...]

Order of destruction: A: 0 A: 1 A: 2 A: 3 ~A: 3 ~A: 2 ~A: 1 ~A: 0

Sorry, the opposite is the correct way: Order of destruction: A: 0 A: 1 A: 2 A: 3 ~A: 0 ~A: 1 ~A: 2 ~A: 3 -Phil

On 4/24/2011 8:35 PM, Phil Bouchard wrote:

I'm happy to say that the code is pretty clean now. All that is left to be done is to make sure multithreading is correct and to use some pool allocator of variable allocation size and having is_from() support.

Ok I just added multithread support. I would like to suggest at the same time to publicize the assignment operator of the class "atomic_count" so that incrementing it of an user-defined step becomes possible. Thanks, -Phil

On 4/25/2011 1:51 PM, Jeremy Maitin-Shepard wrote:

Arguably mm_ptr is a bit too generic: managed is a rather general term that would seem to encompass a wide range of potential strategies, of which your library implements just one. I'm not sure what the best term might be, but the "union" behavior does seem to be a key characteristic.

A key characteristic of mm_ptr is its real-time behavior and could consequently be renamed to rt_ptr or real_ptr for example. On the other hand if garbage collection was to be implemented I'm sure gc_ptr would fit better than mm_ptr. Thanks, -Phil

On 04/25/2011 11:25 PM, Phil Bouchard wrote:

A key characteristic of mm_ptr is its real-time behavior and could consequently be renamed to rt_ptr or real_ptr for example.

On the other hand if garbage collection was to be implemented I'm sure gc_ptr would fit better than mm_ptr.

Thanks, -Phil

If I understood correctly, it's a pointer that 1) counts references from the stack or data segment only 2) auto-unites different "sets" So maybe something along the line of "heap_set_ptr" covers its functionality. I'm curious about the union behaviour: couldn't this be causing a huge delay for deallocation? Can it be turned off? Cheers, Rutger

On 4/26/2011 12:57 AM, Phil Bouchard wrote:

Thanks for the suggestions everybody but I'm now considering: mutual_ptr, which tells what it's made for. The "set" qualifier should be hidden from the user because it'll make the code cleaner.

mutual_ptr or: common_ptr public_ptr joint_ptr allot_ptr I personally prefer the latter so if there's no objection then I'll go for it. -Phil

On 4/26/2011 3:08 PM, Agustín K-ballo Bergé wrote:

On 26/04/2011 19:00, Phil Bouchard wrote:

Excuse me, since I haven't been following this discussion, but what is an "allot"?

Definition: assign; give portion It looks like mutual_ptr is a better choice. -Phil

On 4/26/2011 3:34 PM, Matthew Chambers wrote:

On 4/26/2011 5:00 PM, Phil Bouchard wrote:

None of those seem like very good options: mutual is a synonym for shared.

;)

Even shared_ptr's name does not say what its sharing mechanism is (apparently ref_counted_ptr wasn't popular!), so trying to inject those semantics into a short name is probably asking too much of the name. Algorithms are often qualified by their creators' names: have you considered naming the ptr after the creator of its sharing mechanism? Conceptually, shared_ptr could have had sharing semantics injected by a template parameter (like the RNG concept has semantics injected by algorithms named like mt19937), but obviously it's too late for that.

A policy-based smart pointer encapsulating mm_ptr would have been quite a challenge because of the extra functionality required to initialize pointee objects. Perhaps a smart_ptr class template could be implemented to handle all of shared_ptr, intrusive_ptr, weak_ptr and mm_ptr.

Have you ever met Edward Diener? The reaction of naming affinity vs. naming apathy could power a small country. ;)

The psychologist? I'm careful selecting the right word but so far mutual_ptr wins because it means what it means and won't clash with other keywords. -Phil

Phil Bouchard wrote:

On 4/26/2011 4:20 PM, Phil Bouchard wrote:

...

On 4/26/2011 3:34 PM, Matthew Chambers wrote:

I'm careful selecting the right word but so far mutual_ptr wins because it means what it means and won't clash with other keywords.

I renamed it once more to mutual_ptr and I added a caveat to the documentation. It is accessible here: <https://svn.boost.org/svn/boost/sandbox/mutual_ptr/libs/smart_ptr/doc/tutorial.html>

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? My initial understanding of your class, is that it is a reference counting smart pointer with additional scaffolding, including an allocator, to couple the reference count together with the payload. That much, at least, is like boost::shared_ptr when constructed using boost::make_shared(), as pointed out previously by Nevin, IIRC. So far, your class is little different than shared_ptr, except that you've forced the equivalent of boost::make_shared() without its safety (you require a bald new) or convenience (the new expression is for a distinct type which requires naming the payload type a second time in all uses) to create your pointer type. 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. At any rate, the really unique aspect of your smart pointer class is the memory management. If I understand correctly, you allocate memory from blocks such that when all memory from a block has been released, you release the block too. Thus, the payload for your smart pointer comes from such a block and when there are no stack-based pointers referring to a block, it, and all other smart pointers referring to it, will be released. Assuming I have understood your design reasonably correctly, then the "block allocation" mechanism is the unique feature and suggests the name "block_ptr." BTW, s/instanciate/instantiate/ and s/subdivise/subdivide/ in your docs. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

On 4/25/2011 11:45 PM, Rutger ter Borg wrote:

If I understood correctly, it's a pointer that

1) counts references from the stack or data segment only 2) auto-unites different "sets"

So maybe something along the line of "heap_set_ptr" covers its functionality. I'm curious about the union behaviour: couldn't this be causing a huge delay for deallocation? Can it be turned off?

To answer your question, unifications are very unlikely to start with and they cannot be turned off. -Phil