Alignment of class

[pandionx]

Hi,

This may be a silly question, but I would appreciate some insight into
this.

I know the compiler will align a class' members. However, it is
unclear to me whether the compiler will align the classes themselves.

For example:

#include <iostream>
using namespace std;

struct sa
{
char a;
};

struct sb
{
char a;
char b;
sa c;
char d;

};

void main()
{
sb x;
long aa = (long)(&(x.a));

cout << "a " << (long)&x.a - aa << endl
<< "b " << (long)&x.b - aa << endl
<< "c " << (long)&x.c - aa << endl
<< "d " << (long)&x.d - aa << endl;
}


In the above example I get:

a 0
b 1
c 2
d 3

Now my question is, will the location of c be different on some
platforms, because b is a class? Ie. do some compilers have rules that
a class must always start on a specific boundary? Or is it related to
the first member of the class?

Thanks in advance...

 

[Victor Bazarov]

This may be a silly question, but I would appreciate some insight into
this.

I know the compiler will align a class' members. However, it is
unclear to me whether the compiler will align the classes themselves.

You mean, align objects of that class, right? The answer is, generally,
yes.

For example:

#include <iostream>
using namespace std;

struct sa
{
char a;
};

struct sb
{
char a;
char b;
sa c;
char d;

};

void main()
{
sb x;
long aa = (long)(&(x.a));

cout << "a " << (long)&x.a - aa << endl
<< "b " << (long)&x.b - aa << endl
<< "c " << (long)&x.c - aa << endl
<< "d " << (long)&x.d - aa << endl;
}


In the above example I get:

a 0
b 1
c 2
d 3

Now my question is, will the location of c be different on some
platforms, because b is a class?

Not "will", but "can". Absolutely.

Ie. do some compilers have rules that
a class must always start on a specific boundary? Or is it related to
the first member of the class?

Alignment requirements are platform- and implementation-specific.
If anything is in fact related to the first member of the class,
the Standard has no say in it. Turn to your compiler documentation.

V

 

[JohnQ]

Alignment requirements are platform- and implementation-specific.

Which to me (I am not a compiler implementor.. Yet?!) seems like an
undesireable thing. If I create "Small C++" (name of language TBD),
prohibiting any kind of padding or aligning by the compiler may be a key
feature of the new language. Currently, I compile my programs with the
"byte-align" compiler switch.

John

 

[Victor Bazarov]

Which to me (I am not a compiler implementor.. Yet?!) seems like an
undesireable thing. If I create "Small C++" (name of language TBD),
prohibiting any kind of padding or aligning by the compiler may be a
key feature of the new language. Currently, I compile my programs
with the "byte-align" compiler switch.

Whatever achieves the alignment you require. Not guaranteed to exist
on every platform.

V

 

[Pete Becker]

Whatever achieves the alignment you require. Not guaranteed to exist
on every platform.

And that's because it won't work on some platforms. Alignment
requirements aren't just something that comiler writers make up. They
come from the hardware.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[JohnQ]

Whatever achieves the alignment you require. Not guaranteed to exist
on every platform.

I think what I am searching for is what machines to restrict deployment on.
And also, to evaluate if restricting to machines that are
"alignment-friendly" is viable. If there are offerings at each "level" that
are suitable for the range of applications, then I might be OK. For
instance, it may be easy to say "I just want to deploy on Intel desktop
style boxes". Fine, but if I really want to resuse some code on a PDA also,
will I be able to find PDAs that are like the desktops wrt alignment,
endianess, byte size? I don't think C++ does an adequate job of abstracting
the hardware: it requires that you think about it a lot during development.

Ideally, I think I want: 8-bit bytes, ability to byte-align anything (the
only alignment the language supports), little endian. Maybe the compiler
could enforce transparently on other hardware. 'transparently' is the key.
The goal being that a struct is the same everywhere all the time. In memory
of any machine, on disk, in an IP packet (is there anywhere else?). Without
having to worry about byte size, alignment and endianess, programming
becomes much easier.

John

 

[JohnQ]

And that's because it won't work on some platforms. Alignment requirements
aren't just something that comiler writers make up. They come from the
hardware.

And what I'm wondering is if it is potentially viable (no matter how
far-reaching it may seem) to have more agreement on byte-size, alignment,
endianness. Could software (perhaps a successful language) nudge hardware
vendors toward commonality? Does byte size, alignment and endianness design
freedom actually provide significant value (other than product
differentiation) or is it just as good one way as the other?

John

 

[Ian Collins]

And what I'm wondering is if it is potentially viable (no matter how
far-reaching it may seem) to have more agreement on byte-size, alignment,
endianness. Could software (perhaps a successful language) nudge hardware
vendors toward commonality? Does byte size, alignment and endianness design
freedom actually provide significant value (other than product
differentiation) or is it just as good one way as the other?

It would be an unnecessary constraint on hardware.

 

[JohnQ]

It would be an unnecessary constraint on hardware.

At the expense of billions of hours of programming headaches? "unnecessary"
is in the eyes of the beholder apparently. Surely it can be and has been
studied and someone (from the hardware part of the industry?) can say
conclusively whether there is benefit and what it is or if it's just failure
to choose and simplify.

John

 

[Ian Collins]

At the expense of billions of hours of programming headaches? "unnecessary"
is in the eyes of the beholder apparently. Surely it can be and has been
studied and someone (from the hardware part of the industry?) can say
conclusively whether there is benefit and what it is or if it's just failure
to choose and simplify.

Do you seriously think makers of big-endian processors are going to
change to little-endian or vice versa?

Endian issues are almost as old a computing and have been solved for
almost as long.

 

[JohnQ]

Do you seriously think makers of big-endian processors are going to
change to little-endian or vice versa?

Well first I was wondering if there was reason for the differentiation.
Whether they change of not is their perogative. It's my perogative similarly
to specify what hardware my software will run on. Why make unnecessary
concession to hardware vendors just because they can't get on the same page?

Endian issues are almost as old a computing and have been solved for
almost as long.

"solved" is subjective. If it requires coding a certain way, I'd say the
problem is still open and on the books waiting to be solved.

John

 

[James Kanze]

"Victor Bazarov" <[email protected]> wrote in message

[...]

Ideally, I think I want: 8-bit bytes, ability to byte-align anything (the
only alignment the language supports), little endian.

In other words, a PC.

Maybe the compiler
could enforce transparently on other hardware. 'transparently' is the key.
The goal being that a struct is the same everywhere all the time. In memory
of any machine, on disk, in an IP packet (is there anywhere else?). Without
having to worry about byte size, alignment and endianess, programming
becomes much easier.

Who worries about them today? If you program cleanly, they have
almost no impact; in 25 years of C/C++, the only time I've
worried about byte order was when implementing the C standard
library; in functions like modf, I needed to extract the
exponent field from an IEEE double, and there wasn't long long
at the time. For anyone working at a higher level, they're
irrelevant.

For external formats, of course, you have to program to what was
specified. Most are big endian, but I've also seen variable
length little endian.

 

[Pete Becker]

[...]
Ideally, I think I want: 8-bit bytes, ability to byte-align anything (the
only alignment the language supports), little endian.

In other words, a PC.

Yes, but with a caution: misaligned data can require extra bus cycles to
read and write, so may hurt speed.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[Bo Persson]

JohnQ wrote:
::
:: Well first I was wondering if there was reason for the
:: differentiation. Whether they change of not is their perogative.
:: It's my perogative similarly to specify what hardware my software
:: will run on. Why make unnecessary concession to hardware vendors
:: just because they can't get on the same page?
::
::: Endian issues are almost as old a computing and have been solved
::: for almost as long.
::
:: "solved" is subjective. If it requires coding a certain way, I'd
:: say the problem is still open and on the books waiting to be
:: solved.

It is easy, you either

1. Tell IBM to give up the mainframe backward compatibility of the
past 45 years
or
2. Tell Intel to give up the compatibility with every PC ever made


Your choice!


Bo Persson

 

[Bo Persson]

JohnQ wrote:

:: I don't think C++ does an adequate job of abstracting the hardware:
:: it requires that you think about it a lot during development.

No, it does not. It has lots of abstract types, like int and float.


:: Ideally, I think I want: 8-bit bytes, ability to byte-align
:: anything (the only alignment the language supports), little
:: endian.

It is only when you want to have a non-abstract access to the
underlying hardware that the abstraction fails. No surprise at all!


Bo Persson

 

[JohnQ]

JohnQ wrote:
::
:: Well first I was wondering if there was reason for the
:: differentiation. Whether they change of not is their perogative.
:: It's my perogative similarly to specify what hardware my software
:: will run on. Why make unnecessary concession to hardware vendors
:: just because they can't get on the same page?
::
::: Endian issues are almost as old a computing and have been solved
::: for almost as long.
::
:: "solved" is subjective. If it requires coding a certain way, I'd
:: say the problem is still open and on the books waiting to be
:: solved.

It is easy, you either

1. Tell IBM to give up the mainframe backward compatibility of the past 45
years
or
2. Tell Intel to give up the compatibility with every PC ever made


Your choice!

I wish it was just those two. Then the (my) choice is easy: code to Intel
and don't worry about IBM since the desktop is my target anyway. That (the
desktop) would then be the specific "domain" the new language would be used
in. Simple as pie.

John

 

[JohnQ]

"Victor Bazarov" <[email protected]> wrote in message

[...]

Ideally, I think I want: 8-bit bytes, ability to byte-align anything (the
only alignment the language supports), little endian.

"In other words, a PC."

Yes, but that's not enough anymore today with all the mobility stuff, I
realize that.

Maybe the compiler
could enforce transparently on other hardware. 'transparently' is the key.
The goal being that a struct is the same everywhere all the time. In
memory
of any machine, on disk, in an IP packet (is there anywhere else?).
Without
having to worry about byte size, alignment and endianess, programming
becomes much easier.

"Who worries about them today? If you program cleanly, they have
almost no impact; in 25 years of C/C++, the only time I've
worried about byte order was when implementing the C standard
library; in functions like modf, I needed to extract the
exponent field from an IEEE double, and there wasn't long long
at the time. For anyone working at a higher level, they're
irrelevant."

You've never used the htons() function? You've never wanted a cross-platform
disk file format?

"For external formats, of course, you have to program to what was
specified. Most are big endian, but I've also seen variable
length little endian."

Well see, there ya go. (But there are many more little endian machines out
there than big endian).

John