Is there any advantage or benefit to writing a class as:

class SomeClass
{
   float number[3];
   //...
}

Instead of:

class SomeClass
{
   float number1;
   float number2;
   float number3;
   //...
}

I see a lot of C++ classes that are like the first. Could it be memory alignment reasons? Or maybe for speed?

Lucas Goss skrev:
> Is there any advantage or benefit to writing a class as:
> 
> class SomeClass
> {
>    float number[3];
>    //...
> }
> 
> Instead of:
> 
> class SomeClass
> {
>    float number1;
>    float number2;
>    float number3;
>    //...
> }
> 
> I see a lot of C++ classes that are like the first. Could it be memory alignment reasons? Or maybe for speed?
Now lets see.
1. The array version is shorter to write (Imagine 1000 numbers).
2. An array logically groups related values.
3. You can do for and foreach loops over the array.
4. No speed loss with arrays.
5. Should the need arise the static array is quite easy to make dynamic.


Actually, I have a harder time seeing why I would want it the second way? Well except cases when the naming and grouping is set in stone and becomes more logical, like:
class MyPoint {
  float x, y, z;
  // ...
}

// Fredrik Olsson

Fredrik Olsson wrote:

> Lucas Goss skrev:
>> Is there any advantage or benefit to writing a class as:
>> 
>> class SomeClass
>> {
>>    float number[3];
>>    //...
>> }
>> 
>> Instead of:
>> 
>> class SomeClass
>> {
>>    float number1;
>>    float number2;
>>    float number3;
>>    //...
>> }
>> 
>> I see a lot of C++ classes that are like the first. Could it be memory alignment reasons? Or maybe for speed?
> Now lets see.
> 1. The array version is shorter to write (Imagine 1000 numbers).
> 2. An array logically groups related values.
> 3. You can do for and foreach loops over the array.
> 4. No speed loss with arrays.
> 5. Should the need arise the static array is quite easy to make dynamic.
> 
> 
> Actually, I have a harder time seeing why I would want it the second
> way? Well except cases when the naming and grouping is set in stone and
> becomes more logical, like:
> class MyPoint {
>    float x, y, z;
>    // ...
> }
> 
> // Fredrik Olsson

And even then you use arrays, just having

class MyPoint {

   float _point[3];

   float x() { return _point[0]; }
   void x(float newx) { _point[0] = newx; }
   etc;
}

Lars Ivar Igesund

Fredrik Olsson wrote:
> Actually, I have a harder time seeing why I would want it the second way? Well except cases when the naming and grouping is set in stone and becomes more logical, like:
> class MyPoint {
>   float x, y, z;
>   // ...
> }

In that case we can have the best of both worlds:

struct vec3
{
    union
    {
        struct {
            float x, y, z;
        }
        struct {
            float r, g, b;
        }
        float[3] cell;
    }

    // ...
}

Sometimes it's useful to perform operations on just one component of R^3. If the 'cell' index can be calculated earlier and reused, code duplication can be avoided


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

In article <dpo5ud$3m3$1@digitaldaemon.com>, Lars Ivar Igesund says...
>
>Fredrik Olsson wrote:
>
>> Lucas Goss skrev:
>>> Is there any advantage or benefit to writing a class as:
>>> 
>>> class SomeClass
>>> {
>>>    float number[3];
>>>    //...
>>> }
>>> 
>>> Instead of:
>>> 
>>> class SomeClass
>>> {
>>>    float number1;
>>>    float number2;
>>>    float number3;
>>>    //...
>>> }
>>> 
>>> I see a lot of C++ classes that are like the first. Could it be memory alignment reasons? Or maybe for speed?
>> Now lets see.
>> 1. The array version is shorter to write (Imagine 1000 numbers).
>> 2. An array logically groups related values.
>> 3. You can do for and foreach loops over the array.
>> 4. No speed loss with arrays.
>> 5. Should the need arise the static array is quite easy to make dynamic.
>> 
>> 
>> Actually, I have a harder time seeing why I would want it the second
>> way? Well except cases when the naming and grouping is set in stone and
>> becomes more logical, like:
>> class MyPoint {
>>    float x, y, z;
>>    // ...
>> }
>> 
>> // Fredrik Olsson
>
>And even then you use arrays, just having
>
>class MyPoint {
>
>   float _point[3];
>
>   float x() { return _point[0]; }
>   void x(float newx) { _point[0] = newx; }
>   etc;
>}
>
>Lars Ivar Igesund

Or just exploit D's "array properties feature" and remove the class completely:

>   alias float[3] MyPoint;
>   float x(MyPoint _point) { return _point[0]; }
>   float x(MyPoint _point,float newx) { _point[0] = newx; return newx; }
>   /* ... */
>   MyPoint p;
>   p.x = 5.5;

- EricAnderton at yahoo

Fredrik Olsson wrote:
> Lucas Goss skrev:
> 
>> Is there any advantage or benefit to writing a class as:
>>
>> class SomeClass
>> {
>>    float number[3];
>>    //...
>> }
>>
>> Instead of:
>>
>> class SomeClass
>> {
>>    float number1;
>>    float number2;
>>    float number3;
>>    //...
>> }
>>
>> I see a lot of C++ classes that are like the first. Could it be memory alignment reasons? Or maybe for speed?
> 
> Now lets see.
> 1. The array version is shorter to write (Imagine 1000 numbers).
> 2. An array logically groups related values.
> 3. You can do for and foreach loops over the array.
> 4. No speed loss with arrays.
> 5. Should the need arise the static array is quite easy to make dynamic.
> 
> 
> Actually, I have a harder time seeing why I would want it the second way? Well except cases when the naming and grouping is set in stone and becomes more logical, like:
> class MyPoint {
>   float x, y, z;
>   // ...
> }
> 
> // Fredrik Olsson

I think he's referring to using arrays to group non-related things, because, come to think of it, if the things were logically related, you would use a dynamic array.

Hasan Aljudy skrev:
> Fredrik Olsson wrote:
> 
>> Lucas Goss skrev:
>>
>>> Is there any advantage or benefit to writing a class as:
<snip>
>>>
>>> I see a lot of C++ classes that are like the first. Could it be memory alignment reasons? Or maybe for speed?
<snip>
> 
> I think he's referring to using arrays to group non-related things, because, come to think of it, if the things were logically related, you would use a dynamic array.

For grouping things not logically related I see no reason at all to use arrays, a compiler not s good at optimization might even do worse with an array. But more importantly, it is against KISS, keep it simple stupid.

An array is an ordered list of a single type of data, using it for anything else is inviting trouble if you ask me. If you put temperature and stock changes in the same array, you will have to rely on external mechanism, or even worse; coding practices, for knowing what is what. Sure you can say element 0 IS the temp, and element 1 IS the stocks. A good recipe for writing solid and maintainable code is to make it hard to write the code wrong. "Hmm... was the temperature with offset 0 or 1?", is a probably question to rise, and a good one. "Hmm... was the temperature in temp or stockRate?" Os not quite as likely, and the person asking it should be fired on the spot.

Now if I was only better at coding as I preach :).

// Fredrik Olsson

Hasan Aljudy wrote:
> Fredrik Olsson wrote:
> 
>> Actually, I have a harder time seeing why I would want it the second way? Well except cases when the naming and grouping is set in stone and becomes more logical, like:
>> class MyPoint {
>>   float x, y, z;
>>   // ...
>> }
>>
>> // Fredrik Olsson
> 
> 
> I think he's referring to using arrays to group non-related things, because, come to think of it, if the things were logically related, you would use a dynamic array.

Well I was sort of looking for a general reason since I have other classes that are structured differently, but I'm actually working on a vector class at the moment. So yeah I could do an array like:

> Lars Ivar Igesund wrote:
> class MyPoint {
>
>    float _point[3];
>
>    float x() { return _point[0]; }
>    void x(float newx) { _point[0] = newx; }
>    etc;
> }

Of course keeping the "_point" private, and just allowing the x, y, and z properties. But why do that if the properties do nothing but set the value, they might as well be public:

class MyPoint {
public:
   float x, y, z;
   ...
}

Unless there is some benefit to the array? Especially if it's speed. I know in C++ classes (and C structs) there is no guarantee to how the members are aligned. In D?

Now there may be other benefits to using the array that might come in handy that I don't see till later... I was just trying to plan ahead :)

Lucas Goss wrote:
> Well I was sort of looking for a general reason since I have other classes that are structured differently, but I'm actually working on a vector class at the moment. So yeah I could do an array like:


If you are looking to do 3D math I have a fairly compete library.

http://www.cs.uidaho.edu/~temp0092/point_math.d

This is an older version (the newer one is on a differnt system), I will post the newer one in a few hours.

BCS wrote:
> 
> If you are looking to do 3D math I have a fairly compete library.
> 
> http://www.cs.uidaho.edu/~temp0092/point_math.d
> 
> This is an older version (the newer one is on a differnt system), I will post the newer one in a few hours.

Thanks! (sorry I was a little slow to respond).

My vector class actually looked pretty similar (which means I must be doing something right :) ), though I'm using templates so that you can use float, double, or real. I'd post mine but I no longer have a web site (I'll have to remedy that soon).