Glas List: Re: [glas] Reference counting?

From: Neal Becker (ndbecker2_at_[hidden])
Date: 2007-10-16 07:21:57

On Tuesday 16 October 2007, Karl Meerbergen wrote:
> 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

That is exactly what I don't want.  Having different types for a view vs. an 
array will make it much harder to interoperate with other languages.  I 
believe the unified design is more elegant.

An additional benefit of separating a view and memory management is that an 
externally managed blob of memory can be adopted.  This allows 
inter-operation with other array libraries.  For example, suppose we want to 
interoperate with python numpy objects.

If we follow blitz design, then copy constructor will reference the other 
array data.  BUT, copying an expression will not.

dense_vector<double> w (v.copy()) // deep copy
dense_vector<double> w (v * 4) // no need to say (v*4).copy()