access specifiers and memory layout

[Steven T. Hatton]

I just read something interesting in one of the PDFs located here:
http://www.cs.wustl.edu/~schmidt/C++/ Sorry, I don't recall which file it
was, and I'm too lazy to dig it up again ;) It says that the compiler is
obligated to arrange the memory of this class in declaration order:

class InOrder{
public:
int a;
int b;
int c;
};

But a compiler is free to rearrange this:

class AnyOrder{
public: int a;
public: int b;
public: int c;
};

Anybody know about this?

--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Bob Smith]

Steven T. Hatton wrote:

I just read something interesting in one of the PDFs located here:
http://www.cs.wustl.edu/~schmidt/C++/ Sorry, I don't recall which file it
was, and I'm too lazy to dig it up again ;) It says that the compiler is
obligated to arrange the memory of this class in declaration order:

class InOrder{
public:
int a;
int b;
int c;
};

But a compiler is free to rearrange this:

class AnyOrder{
public: int a;
public: int b;
public: int c;
};

Anybody know about this? never heard about that, as far as i know those two are the same,

G

--
http://www.kolumbus.fi/bob.smith

[hbsk]

The allocation for member variables, which are not separated by a
different access specifier, will be in the same order as their
declaration in the class; this is to provide compatibility with C code.
In the above example, the memory layout of an object of InOrder will be
contiguous for a, b, c.
Moreover, if we have protected and also private members, the memory
layout can reorder/group the member variables as follows, irrespective
of their declaration order in the class:

memory layout:
int a, b, c; // public members first
int d, e, f; // protected
int h, i, j; // private in the last.

this is to provide minimal recompilation to the client code whenever
there is any change to the private part/data of the class used.

This is not the only method the compiler follows but this is one of the
many tricks.

[Steven T. Hatton]

Bob Smith wrote:

Steven T. Hatton wrote:

I just read something interesting in one of the PDFs located here:
http://www.cs.wustl.edu/~schmidt/C++/ Sorry, I don't recall which file it
was, and I'm too lazy to dig it up again ;) It says that the compiler is
obligated to arrange the memory of this class in declaration order:

class InOrder{
public:
int a;
int b;
int c;
};

But a compiler is free to rearrange this:

class AnyOrder{
public: int a;
public: int b;
public: int c;
};

Anybody know about this?

never heard about that, as far as i know those two are the same,

G

It looks like Schmidt's right, unless the specification has changed. See
TC++ARM §9.2 page 173.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[leonardo77]

Steven T. Hatton wrote:

It looks like Schmidt's right, unless the specification has changed. See
TC++ARM §9.2 page 173.

ARM is a bit outdated.
Look up in the standard:
§11.1.2.
and
§9.2.12.

[Steven T. Hatton]

leonardo77 wrote:

Steven T. Hatton wrote:

It looks like Schmidt's right, unless the specification has changed. See
TC++ARM §9.2 page 173.

ARM is a bit outdated.
Look up in the standard:
§11.1.2.
and
§9.2.12.

So the specification hasn't changed in this regard.

--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[John Carson]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:nd********************@speakeasy.net

leonardo77 wrote:

Steven T. Hatton wrote:

It looks like Schmidt's right, unless the specification has
changed. See TC++ARM §9.2 page 173.

ARM is a bit outdated.
Look up in the standard:
§11.1.2.
and
§9.2.12.

So the specification hasn't changed in this regard.

I think that 9.2.14 also needs to be looked at. It suggests to me that your
InOrder and AnyOrder must be layout compatible. Alas, the standard doesn't
seem to give a clear statement of what layout-compatible means. As a
practical matter, I would be amazed if any compiler laid the two structs out
in a different order, given that the access specifiers are really a
degenerate case.

--
John Carson

[Steven T. Hatton]

John Carson wrote:

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:nd********************@speakeasy.net

leonardo77 wrote:

Steven T. Hatton wrote:
It looks like Schmidt's right, unless the specification has
changed. See TC++ARM §9.2 page 173.

ARM is a bit outdated.
Look up in the standard:
§11.1.2.
and
§9.2.12.

So the specification hasn't changed in this regard.

I think that 9.2.14 also needs to be looked at. It suggests to me that
your InOrder and AnyOrder must be layout compatible. Alas, the standard
doesn't seem to give a clear statement of what layout-compatible means. As
a practical matter, I would be amazed if any compiler laid the two structs
out in a different order, given that the access specifiers are really a
degenerate case.

I too would be quite surprised if it made a difference. The only reason I
could see for that would be some kind of space optimization if the members
were of different type. It does, however, suggest that

class Klass{
public:
int a;
private:
int b;
public:
int c;
};

might get re-suffled.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[leonardo77]

Steven T. Hatton wrote:

So the specification hasn't changed in this regard.

Sorry! I was a bit confused about your statement.

[John Carson]

"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:1M********************@speakeasy.net

John Carson wrote:

I think that 9.2.14 also needs to be looked at. It suggests to me
that your InOrder and AnyOrder must be layout compatible. Alas, the
standard doesn't seem to give a clear statement of what
layout-compatible means. As a practical matter, I would be amazed if
any compiler laid the two structs out in a different order, given
that the access specifiers are really a degenerate case.

I too would be quite surprised if it made a difference. The only
reason I could see for that would be some kind of space optimization
if the members were of different type. It does, however, suggest that

class Klass{
public:
int a;
private:
int b;
public:
int c;
};

might get re-suffled.

That is certainly a possibility.

--
John Carson

[Steven T. Hatton]

leonardo77 wrote:

Steven T. Hatton wrote:

So the specification hasn't changed in this regard.

Sorry! I was a bit confused about your statement.

Nothing to apologize for. You cleared up the matter. The Standard could
well have changed. I was simply communicating the fact to the rest of the
folks here.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell