Re: Memory layout question
On Sep 11, 10:42 am, Erik Wikstr=F6m <Erik-wikst...@telia.com> wrote:
On 2007-09-11 09:52, James Kanze wrote:
On Sep 10, 5:13 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
Juha Nieminen wrote:
Craig Scott wrote:
As Victor has mentioned in his posted reply, order is guaranteed,
I wonder why. Assume that a compiler sees that by reordering the
elements in a class/struct it could become more efficient. But since
the standard guarantees that the order is preserved, the compiler
can't do it. But why does the standard say this?
Consider asking the "why" questions in 'comp.std.c++'. They know
(and discuss) the rationales behind all elements of the Standard,
even the smallest ones. I can only speculate that reordering of
members in a struct would definitely interfere with how 'offsetof'
macro would work and how binary streaming of C structs would be
totally broken (once the struct is written, there would be no way
to read it back if you don't know the order of members).
There's no way now, since you don't know where and if padding is
present. (I'll admit that I have no idea why this rule is
present, either. I can't think of any real use one could
possibly make of it in a program.)
I would guess for binary compatibility, there are times when you might
want to write data in a binary format to files but do not require
platform independence.
But imposing the order doesn't change anything here. If you're
compiling both the writer and the reader with exactly the same
compiler (same version, same options, on the same machine), then
the layouts (and representations) will be exactly the same, both
with regards to order and with regards to padding. Throw in a
different option, or update the compiler, and who knows. As
I've mentionned before, in at least one case, a compiler changed
the byte order of long between versions. And a lot of compilers
have options which affect the padding (or, for that matter, the
size of a long).
One example might be to communicate large amounts
of data between different processes, on disk temp storage, or simply to
store data. Efficiency can be gained if one can simply read/write
structs instead of going through all the steps needed for proper
serialisation, of course if it's non-PODs or the structs have pointers
to other variables this is not possible. What I am trying to say is that
if the order of the members are not well defined, different
configurations (optimisations etc.) would make that impossible.
To make such code work, you need more than just the same order.
You need the same padding, and the same representation. If the
layout and the representation are allowed to vary in any way, I
don't see what one minor restriction buys you.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34