«

Hi there. Is this code portable between platforms? Is it also 100% standard
compliant?

#include <iostream>
using namespace std;

class Point {
public:
enum COORDS { X = 0, Y, Z };
Point(int x, int y, int z) : _x(x), _y(y), _z(z) {}

const int& operator[](COORDS c) const
{ return (&_x)[c]; }

private:
int _x, _y, _z;
};

int main() {
Point p(1, 2, 3);

cout << p[Point::X] << endl;
cout << p[Point::Y] << endl;
cout << p[Point::Z] << endl;
}

Is it save to get the address of the first member, and do pointer arithmetic
on it to get to all 3 elements?

Thanx
Martin



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

"Martin Vorbrodt" <> wrote in message
news:ck6adr$her$...
> Hi there. Is this code portable between platforms? Is it also 100%
> standard
> compliant?

No, and no.

But why would you want to write code like this?

john

John Harrison wrote:

> Martin Vorbrodt wrote:

> > Hi there. Is this code portable between platforms? Is it also 100%
> > standard
> > compliant?
>
> No, and no.

The data members were within one private: tag, so their order is
well-defined, and their paddings are implementation-defined.

The second rule makes them non-portable.

So, John, why are they not 100% standard compliant?

> But why would you want to write code like this?

Because OpenGL rewards you to. It permits many variations of its methods to
take an array of indices as a primitive "point object".

The OP is advised to assert() that the size of Point equals the size of
three ints, and keep going. Unless if John can talk him out of it.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

* Phlip:
> John Harrison wrote:
>
> > Martin Vorbrodt wrote:
>
> > > Hi there. Is this code portable between platforms? Is it also 100%
> > > standard
> > > compliant?
> >
> > No, and no.
>
> So, John, why are they not 100% standard compliant?

The program has undefined effect due to invalid pointer arithmetic
(via indexing). My experience is that you'll probably respond to
that by demanding some further justification. And to respond to
that response in advance, look up the rules for valid pointer values.


> > But why would you want to write code like this?
>
> Because OpenGL rewards you to. It permits many variations of its methods to
> take an array of indices as a primitive "point object".
>
> The OP is advised to assert() that the size of Point equals the size of
> three ints, and keep going. Unless if John can talk him out of it.

That's very bad advice because undefined effect is unnecessary.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"Phlip" <> wrote in message
news:uLS9d.6832$ m...
> John Harrison wrote:
>
>> Martin Vorbrodt wrote:
>
>> > Hi there. Is this code portable between platforms? Is it also 100%
>> > standard
>> > compliant?
>>
>> No, and no.
>
> The data members were within one private: tag, so their order is
> well-defined, and their paddings are implementation-defined.
>
> The second rule makes them non-portable.
>
> So, John, why are they not 100% standard compliant?

I guess it depends what you mean by standard compliant. I said no because
dubious pointer arithmetic in the Point class potentially allows access to
padding bytes resulting in undefined behaviour.


>
>> But why would you want to write code like this?
>
> Because OpenGL rewards you to. It permits many variations of its methods
> to
> take an array of indices as a primitive "point object".
>

I can't see the advantage of the OP's code over this, which is portable and
standards compliant

class Point {
public:
enum COORDS { X = 0, Y, Z };
Point(int x, int y, int z)
{
_val[X] = x;
_val[Y] = y;
_val[Z] = z;
}

const int& operator[](COORDS c) const
{ return _val[c]; }

private:
int _val[3];
};

> The OP is advised to assert() that the size of Point equals the size of
> three ints, and keep going. Unless if John can talk him out of it.
>

The OP's code is very likely to work in practice, but it seems to me that
100% complaint code could do as well, and should be preferred.

john

John Harrison wrote:
> "Phlip" <> wrote in message
> news:uLS9d.6832$ m...
>
>>John Harrison wrote:
>>
>>
>>>Martin Vorbrodt wrote:
>>
>>>>Hi there. Is this code portable between platforms? Is it also 100%
>>>>standard
>>>>compliant?
>>>
>>>No, and no.
>>
>>The data members were within one private: tag, so their order is
>>well-defined, and their paddings are implementation-defined.
>>
>>The second rule makes them non-portable.
>>
>>So, John, why are they not 100% standard compliant?
>
>
> I guess it depends what you mean by standard compliant. I said no because
> dubious pointer arithmetic in the Point class potentially allows access to
> padding bytes resulting in undefined behaviour.
>
>
>
>>>But why would you want to write code like this?
>>
>>Because OpenGL rewards you to. It permits many variations of its methods
>>to
>>take an array of indices as a primitive "point object".
>>
>
>
> I can't see the advantage of the OP's code over this, which is portable and
> standards compliant
>
> class Point {
> public:
> enum COORDS { X = 0, Y, Z };
> Point(int x, int y, int z)
> {
> _val[X] = x;
> _val[Y] = y;
> _val[Z] = z;
> }
>
> const int& operator[](COORDS c) const
> { return _val[c]; }
>
> private:
> int _val[3];
> };
>
>
>>The OP is advised to assert() that the size of Point equals the size of
>>three ints, and keep going. Unless if John can talk him out of it.
>>
>
>
> The OP's code is very likely to work in practice, but it seems to me that
> 100% complaint code could do as well, and should be preferred.
>
> john
>
>

I thought identifiers with leading underscores were reserved
for the compiler / implementation's usage. If this is so,
then it is not portable (because some compilers may have
identifiers with those names).

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

>
> I thought identifiers with leading underscores were reserved
> for the compiler / implementation's usage. If this is so,
> then it is not portable (because some compilers may have
> identifiers with those names).
>

Only when those identifiers are at namespace scope. Within a class or a
function they are OK.

john

"Thomas Matthews" <> wrote in
message news:...
> John Harrison wrote:
> > "Phlip" <> wrote in message
> > news:uLS9d.6832$ m...
> >
> >>John Harrison wrote:
> >>
> >>
> >>>Martin Vorbrodt wrote:
> >>
> >>>>Hi there. Is this code portable between platforms? Is it also 100%
> >>>>standard
> >>>>compliant?
> >>>
> >>>No, and no.
> >>
> >>The data members were within one private: tag, so their order is
> >>well-defined, and their paddings are implementation-defined.
> >>
> >>The second rule makes them non-portable.
> >>
> >>So, John, why are they not 100% standard compliant?
> >
> >
> > I guess it depends what you mean by standard compliant. I said no
because
> > dubious pointer arithmetic in the Point class potentially allows access
to
> > padding bytes resulting in undefined behaviour.
> >
> >
> >
> >>>But why would you want to write code like this?
> >>
> >>Because OpenGL rewards you to. It permits many variations of its methods
> >>to
> >>take an array of indices as a primitive "point object".
> >>
> >
> >
> > I can't see the advantage of the OP's code over this, which is portable
and
> > standards compliant
> >
> > class Point {
> > public:
> > enum COORDS { X = 0, Y, Z };
> > Point(int x, int y, int z)
> > {
> > _val[X] = x;
> > _val[Y] = y;
> > _val[Z] = z;
> > }
> >
> > const int& operator[](COORDS c) const
> > { return _val[c]; }
> >
> > private:
> > int _val[3];
> > };
> >
> >
> >>The OP is advised to assert() that the size of Point equals the size of
> >>three ints, and keep going. Unless if John can talk him out of it.
> >>
> >
> >
> > The OP's code is very likely to work in practice, but it seems to me
that
> > 100% complaint code could do as well, and should be preferred.
> >
> > john
> >
> >
>
> I thought identifiers with leading underscores were reserved
> for the compiler / implementation's usage.

Only those at namespace or 'global' scope.

However, I've adopted the practice of not using them at
all, obviating the need to even consider the details of
rules like this.

-Mike

John Harrison wrote:

> I guess it depends what you mean by standard compliant. I said no because
> dubious pointer arithmetic in the Point class potentially allows access
to
> padding bytes resulting in undefined behaviour.

That's implementation-defined. But I have not read the other posts yet...

> I can't see the advantage of the OP's code over this, which is portable
and
> standards compliant

I added the syntactic sugar the OP wanted:

> class Point {
> public:
> enum COORDS { X = 0, Y, Z };

int &x_;
int &y_;
int &z_;

> Point(int x, int y, int z)
: x_(_val[X]),
y_(_val[Y]),
z_(_val[Z])
> {
> _val[X] = x;
> _val[Y] = y;
> _val[Z] = z;
> }
>
> const int& operator[](COORDS c) const
> { return _val[c]; }
>
> private:
> int _val[3];
> };

New question: Is taking a reference to the storage where a variable will be
before it initializes defined?

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Alf P. Steinbach wrote:

> The program has undefined effect due to invalid pointer arithmetic
> (via indexing). My experience is that you'll probably respond to
> that by demanding some further justification. And to respond to
> that response in advance, look up the rules for valid pointer values.

Point to a valid object, NULL, or one off the end of an array..? Nope - not
gonna ask.

(I'm still waiting to hear if you found a real reason to disliked my TEST_
macro, besides I wrote it.)

> > The OP is advised to assert() that the size of Point equals the size of
> > three ints, and keep going. Unless if John can talk him out of it.
>
> That's very bad advice because undefined effect is unnecessary.

Code dealing with Points, such as OpenGL code, typically undergoes sick
optimizations. Naturally I have seen worse than my bad advice.

Even applying my other post might degrade performance, when the compiler
can't optimize the references away fully.

Oh, and would those references make the Point a non-PODs? So the pointer
trick might have another reason to be less defined?

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces