Glas :Re: [glas] Reference counting? |
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2007-10-12 11:08:29
Dear List,
I would like to continue this discussion since it may lead to a
significant change in the development of the library.
I see several situations, where containers could be destroyed before the
view. So, a reference count is indeed useful.
One of my previous colleagues needed fixed size vectors of small size
for a finite element code. He refused to use ublas vectors because the
storage of the size created extra memory overhead.
Do you see (other) situations where the storage of a reference could
create overhead?
As for smart pointers, we can have different views. A view could take
ownership of the container (as for an auto_ptr, e.g.). The reference
count would not be needed and this would make people happy who use small
vectors.
More important, I think, is the issue about the assignment operator and
the copy constructor.
Currently, the copy constructor makes a shallow copy for all views and
expression objects, while the assignment operator is a deep copy. This
looks like a conflicting situation. UBlas does the same I think. What
about MTL?
I am not very keen on giving up the deep copy concept of w = v. Does
anyone have an interesting idea?
Best,
Karl
Russell Smiley wrote:
>>-----Original Message-----
>>From: Russell Smiley
>>Subject: Re: [glas] Reference counting?
>>
>>
>>
>>>-----Original Message-----
>>>From: Karl Meerbergen
>>>Subject: Re: [glas] Reference counting?
>>>
>>>* if v and w are two vectors (or vector views), what does the
>>>operation
>>>w = v do ?
>>>
>>>
>>>
>>In my implementation of a reference counted object w=v means that w
>>drops the reference to its current storage (with a resulting decrement
>>to the reference count for that object) and then picks up the
>>reference
>>to the storage in v with a resulting increment to that
>>reference count.
>>I think this is the most useful for general application.
>>
>>If you want to copy values from the v storage into the w storage then
>>there are two separate methods:
>>
>>w.value_copy(v) - copies values from v, but w dereferences current
>>storage and creates a new 'blank' storage before the copy.
>>
>>w.value_copy_this_reference(v) - copies values from v into the current
>>storage of w.
>>
>>
>>
>
>I forgot there is a third method:
>
>w.value_copy() which tells w to start a reference to new storage copying
>the values from the old storage.
>
>Russell.
>_______________________________________________
>glas mailing list
>glas_at_[hidden]
>http://lists.boost.org/mailman/listinfo.cgi/glas
>
>