containers or array types gubbins

[bartek]

Hello,

It is not possible to assign values to, say, a vector<float[3]> due to the
fact that arrays are not assignable.
Theoretically there's a simple workaround which involves wrapping the array
in a struct, e.g.

struct float3
{
float m[3];
};

....and then using vector<float3>
The problem with this approach is, that there's no guarantee that
sizeof(float[3]) == sizeof(float3).

My question boils down to: is there any non-contrived generic way to treat
containers of array types in an analogous way to non-array types?

Cheers,
b
--
:: bartekd [at] o2 [dot] pl

[Victor Bazarov]

bartek wrote:

It is not possible to assign values to, say, a vector<float[3]> due to the
fact that arrays are not assignable.
I think it's actually stricter than that. You just cannot have
vector<float[3]>, period.
Theoretically there's a simple workaround which involves wrapping the array
in a struct, e.g.

struct float3
{
float m[3];
};

...and then using vector<float3>
Why "theoretically"? It's a work-around. Work-arounds are always
practical, not theoretical.
The problem with this approach is, that there's no guarantee that
sizeof(float[3]) == sizeof(float3).
Why do you think it's a problem? sizeof(float3::m) == sizeof(float[3])
What doesn't the difference in sizes between the struct and its member
let you achieve? Are you concerned with the fact that an array of, say,
10 float3 will not be the same as 10*3*sizeof(float)? Is that _really_
so important? Why? Do you need to read an array (vector's storage) of
those structs in one huge 'read' operation? Can you not split it into
several smaller ones?

My question boils down to: is there any non-contrived generic way to treat
containers of array types in an analogous way to non-array types?

Well, where standard containers are concerned, there are no "containers
of array types". If you devise your own container (that doesn't have to
satisfy container requirements put forth by the Standard), you can have
whatever you want, and it's probably not going to be "contrived" (whatever
you mean by that).

Victor

[bartek]

Victor Bazarov <v.********@comAcast.net> wrote in
news:V3***************@newsread1.dllstx09.us.to.ve rio.net:

bartek wrote:

It is not possible to assign values to, say, a vector<float[3]> due
to the fact that arrays are not assignable.

I think it's actually stricter than that. You just cannot have
vector<float[3]>, period.

Theoretically there's a simple workaround which involves wrapping the
array in a struct, e.g.

struct float3
{
float m[3];
};

...and then using vector<float3>

Why "theoretically"? It's a work-around. Work-arounds are always
practical, not theoretical.

Theoretically for me. Some workarounds are more practical than others.
See below.

The problem with this approach is, that there's no guarantee that
sizeof(float[3]) == sizeof(float3).

Why do you think it's a problem? sizeof(float3::m) ==
sizeof(float[3]) What doesn't the difference in sizes between the
struct and its member let you achieve? Are you concerned with the
fact that an array of, say, 10 float3 will not be the same as
10*3*sizeof(float)? Is that _really_ so important? Why? Do you need
to read an array (vector's storage) of those structs in one huge
'read' operation? Can you not split it into several smaller ones?

I'm dealing with a C API which uses pointers to arrays of arrays all
around its interfaces.
Those arrays are usually quite big. Therefore I want to keep them in my
C++ code in a binary compatible fashion, so I can get rid of wasteful
copying on the API boundary, and just pass a &*data.begin().

My question boils down to: is there any non-contrived generic way to
treat containers of array types in an analogous way to non-array
types?

Well, where standard containers are concerned, there are no
"containers of array types". If you devise your own container (that
doesn't have to satisfy container requirements put forth by the
Standard), you can have whatever you want, and it's probably not going
to be "contrived" (whatever you mean by that).

Thanks. It seems throwing together a custom container is the way to go.

Cheers.

--
:: bartekd [at] o2 [dot] pl