Re: Struct members -> Array elements

Firstly, I did make a typo in my original post; I should have written:

    double *p = &obj.a;

(I left out the ampersand in my original post).

I'll reply in sequence to the replies which have been posted thus far.

kanze posted:

<in reference to my proposal>


We would be able to write:

    struct Monkey {

        union {
            double array[5];

            struct {
                double a;
                double b;
                double c;
                double d;
                double e;
            };
         };

    };

rather than:

    class Monkey {
    public:
        double array[5];

        double &a, &b, &c, &d, &e;

        Monkey() : a(*array),
                   b(array[1]),
                   c(array[2]),
                   d(array[3]),
                   e(array[4]) {}
    };

The first form is prefereable as it's a POD, there's no need for a
constructor, and there's no need to complicate things with references.

Greg Herlihy posted:


<snip>


It's a minority who are prepared to make that assertion (as you can see
from the replies). I do agree with your logic... (which is why I started
this thread)... but it seems that some people here are quick to discredit=
 
the code as simply being incorrect, stating that the code makes a false
presumption that the double's are positioned right after one another in
memory.

The purpose of my proposal is that the Standard will explicitly state in
plain English that there's no padding, such that the topic won't even be
open for debate as it is now.

Ducky Yazy posted:


My argument is that there shouldn't be any padding because the objects ar=
e
of the same type, and thus should fit neatly one after another in memory.=
 
(The padding needed at the end of a struct is already taken into account =
by
"sizeof", and this value is used in pointer arithmetic -- which is how we=
 
get the desired behaviour of using a pointer to go through an array).

Francis Glassborow posted:


It would improve the language. (If the committee time is "too valuable" t=
o
consider improving the language, then maybe we need a new committee).


I am vehemently against this argument. The Fancy Class Types we have in C=
++
are built upon the fundamental core functionality of primitive types and
POD's. C++ should progress and improve and get better and better, but it
should never forget that it's built on the core functionality of primitiv=
e
types and POD's. C++ would be a poor language if the following code was
illegal:

struct Monkey {
    union {
        long double a;

        struct {
            int b;
            void* c;
        };
    };

    char d;

    short e;
};

int main()
{
    Monkey obj;

    int * const p = reinterpret_cast<int*>(&obj);

    *p = 67;

    if ( obj.b != 67 ) PeformSomeUndefinedBehaviour();
}
    

I believe that this "core functionality" should be milked for everything
it's worth, stretching it as far as we can, getting every last penny out =
of
it. An advanced programming language with features such as mutliple virtu=
al
inheritance, and templates, would be even better if it was built on a sol=
id
core functionality. We should improve this core functionality by explicit=
ly
stating in the Standard that there's no padding between members of the sa=
me
type within a POD.


 


Can anyone mention one sole platform upon which there would be padding
between members of the same type in a struct? I can't think of any reason=
 
whatsoever why there would be. I'd go on to say that the following two
structures should be exactly the same size:

struct { double a,b,c,d,e };

struct { double array[5] };

-Tom=E1s

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]