From: Georg Baum (Georg.Baum_at_[hidden])
Date: 2007-06-07 03:44:42
Am Donnerstag, 7. Juni 2007 08:55 schrieb Gunter Winkler:
> Am Donnerstag, 7. Juni 2007 06:09 schrieb Server Levent Yilmaz:
> > This is interesting (and obviously works, thank you).. Yet, I can not
> > help but mention that the interface of array_adaptor is quite
> > counter-intuitive. For instance the following :
> > array_vector v(n, array_adaptor(n,array));
> > ends up NOT using the adapted pointer but allocating its own space...
Yes. I also found that out the hard way: My code did not work...
> > Some reading of the source code reveals that array_adaptor is
> > curiously trying to manage its own memory whenever it can (for
> > example at copy construction)... Isn't that the job of
> > unbounded_array? Isn't the whole purpose of array_adaptor is to
> > delegate memory management _wholly_ to the user? (this is no
> > rhetoric, really, what else is array_adaptor used for?)
I'd like to know this, too. In my application I use array_adaptor exactly
like you describe, and it works, because my code never resizes the vector.
Of course it would break apart if I ever changed it so that a resize
Why not make array_adaptor throw an exception on any resizing operation
instead of trying to be 'clever'?
> > And curiously asking if I may, why did carray_adaptor removed?
> > (renamed?)
> uBLAS assumes deep copy semantics on all data types. Thus the usage of
> external storage which can not be reallocated is dangerous and must be
> used very carefully. Thus the shallow array adaptor is disabled by
> default. You can define
Why disable shallow_array_adaptor and not array_adaptor? With the code I
posted you can easily shoot yourself in the foot as well.
> to enable it.
> (see storage.hpp)
> // Array adaptor with shallow (reference) copy semantics of elements.
> // shared_array is used to maintain reference counts.
> // This class breaks the normal copy semantics for a storage container
> // and is very dangerous!
> However, these adaptor are quite experimental and need still more
> testing (and more documentation).
Do you have any use case where reference copy semantics are useful? I can't
imagine one. I also believe that Levent does not want that.
It is clear that wrapping externally allocated storage is dangerous, but
this is the very nature of the problem you want to solve. I don't see how
an array_adaptor that tries to use internal memory could help here.