Boost logo

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

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?



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
>>>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
>>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.
>glas mailing list