Re: Reference counting?

I think that a general-purpose package needs to provide
vector/matrix 
classes taylored to various uses.  An application using many
3d vectors 
will have very different requirements (fast
allocation/deallocation, 
efficient storage) to an application using 1000x1000
matrices (efficient 
manipulation using views/slices).

As I see it, reference counting will improve safety and may
allow 
storage and slicing to be implemented by the same class, but
does not 
introduce extra mathematical functionality. The expense is
probably 
worth it for large objects, but not for small objects.

Regarding the copy semantics, how about introducing a new
concept 
"VectorView" which uses shallow copies to
complement "VectorContainer" 
which uses deep copies? It seems like this concept is
sufficiently 
important to be worth adding, though I generally think it's
important to 
keep the number of different concepts to a minimum.

Presumably it would be possible to separate storage
(including reference 
counting) from the rest of the code by using an array
template argument 
similar to uBlas.

Regards,

Pieter


-- 

Dr. Pieter Collins
Centrum voor Wiskunde en Informatica
Postbus 94079
1090 GB Amsterdam
The Netherlands

Tel: +31 20 5924196
Fax:  +31 20 5924199
Email: Pieter.Collinscwi.nl

_______________________________________________
glas mailing list
glaslists.boost.org
http
://lists.boost.org/mailman/listinfo.cgi/glas

Pieter Collins wrote:

>I think that a general-purpose package needs to provide
vector/matrix 
>classes taylored to various uses.  An application using
many 3d vectors 
>will have very different requirements (fast
allocation/deallocation, 
>efficient storage) to an application using 1000x1000
matrices (efficient 
>manipulation using views/slices).
>
>As I see it, reference counting will improve safety and
may allow 
>storage and slicing to be implemented by the same class,
but does not 
>introduce extra mathematical functionality. The expense
is probably 
>worth it for large objects, but not for small objects.
>
>Regarding the copy semantics, how about introducing a
new concept 
>"VectorView" which uses shallow copies to
complement "VectorContainer" 
>which uses deep copies? It seems like this concept is
sufficiently 
>important to be worth adding, though I generally think
it's important to 
>keep the number of different concepts to a minimum.
>
>Presumably it would be possible to separate storage
(including reference 
>counting) from the rest of the code by using an array
template argument 
>similar to uBlas.
>
>Regards,
>
>Pieter
>
>
>  
>

Hi Pieter,

At this stage, there is no container concept in GLAS, so all
options are 
still open. I am in favour of having two container concepts,
as you 
suggest, View and Container, one with a deep copy
constructor, the other 
with a shallow copy constructor. I am currently using a
shared_ptr for 
this instead of a view.

If two types of containers exist, the user has to be aware
of the 
difference in behaviour between copy constructors.

I am not sure that a template argument is good enough to
make clear that 
the copy constructor has different behaviour ?!

Currently you can do something like

dense_vector<double> v( 10 ) ;
dense_vector<double> w( 4.0 * v ) ;

This does not make sense with a shallow copy. In the case of
a shallow 
copy, this could become:

dense_vector<double> v( 10 ) ;
dense_vector<double> w( size(v) ) ; w = 4.0 * v ;

Best regards,

Karl


_______________________________________________
glas mailing list
glaslists.boost.org
http
://lists.boost.org/mailman/listinfo.cgi/glas