[Boost-users] multi_array_ref (lack of) default constructor

[gtsml owevwr]

Hi,

Does anybody know why multi_array_ref doesn't have a default constructor?

I'm asking because I wanted to make a multi_array of multi_array_ref
and that doesn't seem to be possible because multi_array expect the
element type to be default constructible.

Thanks,
Frank
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Robert Jones]

On Fri, May 29, 2009 at 1:12 PM, gtsml owevwr <gtsml....@googlemail.com> wrote:

Hi,

Does anybody know why multi_array_ref doesn't have a default constructor?

I'm asking because I wanted to make a multi_array of multi_array_ref
and that doesn't seem to be possible because multi_array expect the
element type to be default constructible.

I don't know, but if it did what would you have it do? Surely it lacks
one for the same reason that references must be initialised?

- Rob.

[Anton Daneyko]

Could you please explain in more detail the way you're going to use that? I'm quite new to multi_array, so I am interested in how people apply that.  

[gtsml owevwr]

> I don't know, but if it did what would you have it do? Surely it lacks
> one for the same reason that references must be initialised?

Yes, that's absolutely right, I just realized that multi_array_ref
exactly mimic the C++ ref (probably obvious).

I originally thought that multi_array_ref will solve the problem I had
with multi_array ownership: the memory chunk I need to work with is
already owned by another class. But multi_array_ref is too restrictive
for my purpose. As I said, I need to pass a vector of those and that's
just not possible.

I'm not explaining it too well but the bottom line is that from my
perspective multi_array_ref is:
- good because it doesn't own the data
- bad because it act as a ref:
- no default constructor
- operator= is a deep copy

Ideally, I'm looking for what most people call "a view". Probably
playing with words here, but definitely, multi_array_ref is not what I
am looking for.

[Robert Jones]

On Sun, May 31, 2009 at 2:11 PM, gtsml owevwr <gtsml....@googlemail.com> wrote:

> I don't know, but if it did what would you have it do? Surely it lacks
> one for the same reason that references must be initialised?

Yes, that's absolutely right, I just realized that multi_array_ref
exactly mimic the C++ ref (probably obvious).

I originally thought that multi_array_ref will solve the problem I had
with multi_array ownership: the memory chunk I need to work with is
already owned by another class. But multi_array_ref is too restrictive
for my purpose. As I said, I need to pass a vector of those and that's
just not possible.

I'm not explaining it too well but the bottom line is that from my
perspective multi_array_ref is:
- good because it doesn't own the data
- bad because it act as a ref:
  - no default constructor
  - operator= is a deep copy

Ideally, I'm looking for what most people call "a view". Probably
playing with words here, but definitely, multi_array_ref is not what I
am looking for.

Perhaps, but multi_array & multi_array_ref do contain the notion of
a view. They're used to generate slices through the array, but I think
it would be ok to construct a slice which is the whole array, and that
would be your view I believe.

- Rob.


--
ACCU - Professionalism in programming - http://www.accu.org

[gtsml owevwr]

> Perhaps, but multi_array & multi_array_ref do contain the notion of
> a view. They're used to generate slices through the array, but I think
> it would be ok to construct a slice which is the whole array, and that
> would be your view I believe.

That might work actually... Well, at one condition: that the view
doesn't hold any reference to the multi_array_ref.
Let's put it differently, the view needs to be valid even after the
destruction of the multi_array_ref.

I'm going to give it a try but please feel free to comment on this as
I might be missing something...

[gtsml owevwr]

Multi_array view has not default constructor, so I'm stuck with the
same problem.

I guess in the end this is a matter of taste. multi_array seems to be
designed so that objects are always valid at all time.
I'm sure it has lots of advantages, still, for lightweight object such
as a view or multi_array_ref, that might not be necessary.

Ok, I think the only solution left is to use pointers to
multi_array_ref, that should work.
I'd be able to do something along that line (not tested):

std::vector<int> memoryChunk0;
std::vector<int> memoryChunk1;

{
std::vector<multi_array_ref*> v;
v.push_back(new multi_array_ref( <ctor from memoryChunk0 > ));
v.push_back(new multi_array_ref( <ctor from memoryChunk1 >));

myFunction(v);

BOOST_FOREACH( multi_array_ref* ma, v)
{
delete ma;