Re: [boost] Review of Intrusive library begins today March 12

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-03-23 11:59:16

Pavel Vozenilek wrote:
> "Ion Gaztañaga" wrote:
> Pavel Vozenilek wrote:
> 
> _________________________________________________________
>>> * An vector-like pseudo-intrusive container may be added.
>>>   It is superfluous but people may like it more than lists.
>> Well, a vector is not even pseudo-intrusive, because it has no nodes.
>> std::vector<> + allocator is not sufficient in your opinion?
>>
> What I mean is a container that provides operator[].
> 
> Possibly something what keeps an auxiliary array
> in container and where hook has either
> * one back-pointer into the internal array inside container
>   (to allow iterator::operator+(int)).
> * or one back pointer to the container + integer index
>   (this would allow range checking)

Still no convinced. What's the difference with a std::vector with a 
custom allocator?

> The open source library is underdocumented but source is available.

Ok. Thanks.

>>> * when an object is removed from the last container
>>>   it gets automatically deleted.
 > [snip]
> 
> I though about it a bit more since I wrote the review and here's
> how I would structure it (provided it is all technically feasible):
> 
> The library would provide containers and hooks parametrized
> by one more parameter: a boolean OwnsData
> (alternatively differently named containes could exist):
 >
> [snip]
 >
> The containers owning data would:
>  * Always own the data collectively (the last owner destroys it)
>  * Assume the data was *always* allocated with new.
>  * The cloning/assignement/copy constructor may be provided,
>    employing copy constructor or the value and new/delete.
>    (I personally would avoid it too as the semantic is too complicated.)

So something similar to std::list<shared_ptr<T> > but intrusive 
containers. The reference count is shared between all the containers. 
That would require an intrusive_ptr as a member. But again: the 
reference count must be common for all the member. I'm thinking that 
this can be useful to implement an OS-like handle where the handle is an 
intrusive friendly class, but also reference counted. Interesting but 
not trivial to manage. I'll think this should wait until the first 
Intrusive library is out.

>  * Auto-hooking would behave as it does now. After the last
>    hook is unlinked there reference to the value will became invalid.

I don't think so. Auto-unlink works only with containers that are just 
formed with nodes and does not have any other "living" data (like the an 
internal size), because the hooks have no pointer to the container (the 
are like any other hooks). If we want to support auto-unlink for a 
container with "living" data I think we should create a new category of 
linking policy (enhanced auto-unlink) where the hook stores also a 
pointer to the container where it was placed. This will increase 
sensibly the size of a hook (list hook would grow 50%) must this might 
be useful. But I want to maintain the size advantages of the current 
tiny auto-unlink hook. New linking policies might be created if the user 
wants auto-unlinking but size overhead is not an issue.

I'm still not convinced with about linking intrusive containers and 
destruction policy. After all, that the job of an allocator. But anyway, 
I think the idea is interesting but requires more refinement.

> _________________________________________________________
>>> "In intrusive containers you don't store a copy of an object,
>>> but rather the original object itself."
>>>
>>> may be better reworded to avoid "store" which usually implies copying.
>> Ok, but which other word would you use?
>>
> E.g.
> 
> In intrusive containers you don't copy an object into the container
> but rather the original object gets linked together with the other
> objects in the container.

Ok.

>> No, the safe mode is applied for every hook. If you try to insert an
>> object in a container and it's already inserted in another container
>> that uses the same hook, the code will assert.
>>
> 
> I actually intended to write that a value may have more than
> one hook and that the text in usage.html should not talk
> about the whole object.

Ok.

> 
>  ________________________________________________________________
>> 14. using_smart_pointers.html
>>
>> offset pointer should not be called smart pointer.
> 
> Why not? Smart pointers don't need to be related with lifetime
> management issues, as I understand the term. How would you call
> offset_ptr, a "pointer class"?
> ----------------
> 
> I do not like usage of the word "smart" being expanded.
> Here "pointer-like object" or, uggh, "pseudopointer" could be used.

According to Wikipedia (if we can trus:

"In computer science, a smart pointer is an abstract data type that 
simulates a pointer while providing additional features, such as 
automatic garbage collection or bounds checking. These additional 
features are intended to reduce bugs caused by the use of pointers while 
retaining efficiency. Smart pointers typically keep track of the objects 
they point to for the purpose of memory management."

Observe "such as" or "tipically". Smart pointers are normally for memory 
ownership issues but a bounds checking pointer has ownerships semantics.

I think offset_ptr is a smart pointer. Offers additional features like 
memory base address independent.

Regards,

Ion