References referencing array members - how evil is it?

[Asfand Yar Qazi]

Hi,

I've got this class, you see:

class Vec4
{
Vec4();
...
float data[4];
float& x;
float& y;
float& z;
float& w;
...
};

Vec4::Vec4()
: x(data[0]), y(data[1]), z(data[2]), w(data[3])
{
}

So, in code I can do a:

// yes, I know the - is there
Vec4 v = some_stuff + some-other_stuff;

// The following two should be identical
dostuff(v[0]);
dostuff(v.x);

Obviously, this is convenient for me, and increases readability. But
is it something that you would consider ok, no-so-good, or just plain
evil? Would this be portable?

Thanks,
Asfand Yar

 

[Karl Heinz Buchegger]

Hi,

I've got this class, you see:

class Vec4
{
Vec4();
...
float data[4];
float& x;
float& y;
float& z;
float& w;
...
};

Vec4::Vec4()
: x(data[0]), y(data[1]), z(data[2]), w(data[3])
{
}

So, in code I can do a:

// yes, I know the - is there
Vec4 v = some_stuff + some-other_stuff;

// The following two should be identical
dostuff(v[0]);
dostuff(v.x);

Obviously, this is convenient for me, and increases readability. But
is it something that you would consider ok, no-so-good, or just plain
evil? Would this be portable?

It would be portable. Nevertheless I wouldn't use it for the reason
that it most likely increases the class size tremendously. In my vector
classes I don't use an array at all. The need for it isn't that much that
it pays of to have one ready. When I really need such an array (such as
eg in transfer to OpenGL) I simply create it.

BTW: You are aware that you should use double instead of float in most
cases? The memory currently used for holding the references would be better
invested in a change to double.

 

[Rolf Magnus]

Hi,

I've got this class, you see:

class Vec4
{
Vec4();
...
float data[4];
float& x;
float& y;
float& z;
float& w;
...
};

I hope you know that each of those references will take up the same space as
a pointer on pretty much every C++ implementation, so if you're on a
typical 32bit architecture, you have to expect that class to have twice the
size of the data array, on a 64bit plattform, it's likely to be even a
factor of 3.

Vec4::Vec4()
: x(data[0]), y(data[1]), z(data[2]), w(data[3])
{
}

So, in code I can do a:

// yes, I know the - is there
Vec4 v = some_stuff + some-other_stuff;

// The following two should be identical
dostuff(v[0]);
dostuff(v.x);

Obviously, this is convenient for me, and increases readability. But
is it something that you would consider ok, no-so-good, or just plain
evil?

I'd rather do member functions x(), y(), z(), and w() that return references
to the elements, or rather, that's what I actually did in my OpenGL vector
class. ;-)

Would this be portable?

Yes.

 

[Asfand Yar Qazi]

Asfand Yar Qazi wrote:
<snip>

It would be portable. Nevertheless I wouldn't use it for the reason
that it most likely increases the class size tremendously. In my vector
classes I don't use an array at all. The need for it isn't that much that
it pays of to have one ready. When I really need such an array (such as
eg in transfer to OpenGL) I simply create it.

You see, this is for a template expression based component-wise vector
operations framework. So, I need some sort of array-like structure,
since it will be accessed via index operator calls when involved in an
expression.

BTW: You are aware that you should use double instead of float in most
cases? The memory currently used for holding the references would be better
invested in a change to double.

I'm not concerned with space wasteage. Please note, this is for a
software 3D renderer, so I need the fastest floating point ops I can use.

I think I know what I need to do now - thanks for your input, it was
much help.

 

[Asfand Yar Qazi]

Asfand Yar Qazi wrote:
<snip>


I'd rather do member functions x(), y(), z(), and w() that return references
to the elements, or rather, that's what I actually did in my OpenGL vector
class. ;-)

That's what I'll do, I think, so doing a 'v.x() = 4.0f' would work.
Thanks.

 

[Karl Heinz Buchegger]

I'm not concerned with space wasteage. Please note, this is for a
software 3D renderer, so I need the fastest floating point ops I can use.

Have you timed 'float' versus 'double'.
On most systems they have equal performance. The reason is that on
todays hardware the operation is most likely done in an FPU anyway,
which operates with the same precission in any case.

But its your choice. You will quickly seee what wormhole you
opened with float.

 

[Asfand Yar Qazi]

Have you timed 'float' versus 'double'.
On most systems they have equal performance. The reason is that on
todays hardware the operation is most likely done in an FPU anyway,
which operates with the same precission in any case.

But its your choice. You will quickly seee what wormhole you
opened with float.

I still don't understand everybody's opposition to floats, perhaps you
can explain it to me. 4 bytes is quicker to process than 8, isn't it?!

You see, if I'm gonna be using SSE, then I can't use doubles - SSE
from what I can tell can do 4 floats at once, but only 2 doubles at
once. On a Pentium 3 its not a problem, since 4 floats at once is
actually 2 sets of 2 floats, but on better processors like Pentium 4,
4 floats do get done at once.

And since I'm passing around pointers to classes containing floats, I
don't think its a problem.

OK, you win. For arguments sake, I'll test with double (using the old
'#define float double' trick), lets see what I get.

 

[Asfand Yar Qazi]

OK, you win. For arguments sake, I'll test with double (using the old
'#define float double' trick), lets see what I get.

Bloody hell you're right - double ends up being faster.

Sheesh, that's the last time I trust common sense!