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?

 

[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.

 

[Bob Smith]

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

 

[Steven T. Hatton]

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.

 

[leonardo77]

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]

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.

 

[John Carson]

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.

 

[Steven T. Hatton]

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.

 

[leonardo77]

So the specification hasn't changed in this regard.

Sorry! I was a bit confused about your statement.

 

[John Carson]

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.

 

[Steven T. Hatton]

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.