On Aug 7, 8:20 pm, Ville Voutilainen <ville.voutilai...@gmail.com>
wrote:
> On Jul 30, 11:55 pm, "Balog Pal" <p...@lib.hu> wrote:
>
> >And the standard has
> >text stating that members' addresses will rise by the declaration order and
> >all have disctinct addresses.
>
> Could you point to the specific section in the standard where this
> text can
> be found?

The concept is in 9.2/12 "Nonstatic data members of a (non-union)
class declared without an intervening access-specifier are allocated
so that later members have higher addresses within a class object."

The original poster makes a good point, this relationship is further
hampered by the fact that padding can always
be inserted for alignment purposes, or to handle derivation and
virtual functions.   So most code relying on this
isn't portable anyhow.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jul 30, 11:55 pm, "Balog Pal" <p...@lib.hu> wrote:

>And the standard has
>text stating that members' addresses will rise by the declaration order and
>all have disctinct addresses.

Could you point to the specific section in the standard where this
text can
be found?

> I guess just removing the order guarantees we have would not fly due to
> theoretic 'breaking existing code', but what if we could flag the
> free-to-reorder classes?
> IUC 'attributes' are entering the standard, and this kind of extension would
> fit well with it, the only thing needed is an attribute name, and the
> defined semantic. Then a lucky combination of use and supporting compiler
> would create the advantage, and all the rest works like today.

Sounds quite reasonable to me, add some compact_layout attribute,
which
would guarantee exactly that, compact layout. I do wonder if this is
something
that must be guaranteed by the standard, or whether it's a quality-of-
implementation
issue.

> If not, is it worth writing up as a fromal proposal, that could stand real
> chance of inclusion in C++0x this late?

I would suggest writing a proposal and giving it to the Evolution
Working Group.
If you can get it past Evolution, it stands a greater chance of
survival at
the Core Working Group. There's surely going to be some reluctance to
add
much anything at this stage, but it's hard to guesstimate whether
something
like this could get added or not. A formal proposal would at least
result in
the idea not being forgotten.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

IIRC the compiler have serious limitations on how to create layout for
structs and classes. Which roots back to C. Introducing private/public
sections allow some swaps, but it is still limited.  And the standard has
text stating that members' addresses will rise by the declaration order and
all have disctinct addresses.

In my experience code that would depend on such ordering and member
distinction by address is very rare for classes.  And almost all processors
used now have alignment either strictly required or suggested for
performance reasons, for anything but char types.  What in effect leaves us
with much padding.   Eating up memory, and attached other resources for no
good reason.    Or if programmers start to tweak layout avoiding this, kills
readability.  I like to declare members in ligically associated chunks, not
by type -- and not move them as type may change.   (Also, porting changes
width of many types...)

I guess just removing the order guarantees we have would not fly due to
theoretic 'breaking existing code', but what if we could flag the
free-to-reorder classes?

IUC 'attributes' are entering the standard, and this kind of extension would
fit well with it, the only thing needed is an attribute name, and the
defined semantic. Then a lucky combination of use and supporting compiler
would create the advantage, and all the rest works like today.

And implementing the compiler side of support on top of the existing one is
probably trivial too.

Did I miss something?
If not, is it worth writing up as a fromal proposal, that could stand real
chance of inclusion in C++0x this late?



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]