🚀 go-pugleaf

In article <1070@lupine.NCD.COM> rfg@ncd.com writes:
>There already exists a defined way within the language to "turn off the
>standard C++ field ordering restrictions".
>
>Section 9.2 (page 173, middle of the page) in E&S says:
>
>	"The order of allocation of nonstatic data members {which are}
>	separated by an access specifier is implementation dependent (11.1)".

Yes.  So given that access specifiers and/or inheritence can bust people's
expectations on packing order, why maintain restrictions on packing order
at all?  Or why not require special actions, such as adding a "extern "C"'
caveat, be used by people who have the unusual need of matching machine
registers?  What percentage of C++ programmers need to diddle machine
registers, and how often?

>I personally find the rule cited above intensely offensive because it gives
>the compiler licence to thwart the will of the programmer (who is supposed
>to be in control after all).  I don't like that one little bit!

Actually, the will of this programmer is that C++ compilers generate the
fastest and most compact code possible from my class declarations.  It 
is not C++ compilers that are tharting this will, but rather people who
want to continue using C++ as a C assembly language.  I want to be able
to use C++ as a fast, efficient object oriented language.  This requires
compilers that have great optimization, and great freedom to optimize.

There continues this division between C/C++ people who want a compiler
to "do what I say" verses "do you best optimizations."  I think this
issue should be addressed in the marketplace -- not in the language.
If you want a C++ compiler that acts just like C that acts just like
assembler, then surely the marketplace will offer such a compiler from
some vendor.  If you want to use C++ to play with machine registers,
then portability is not an issue to you anyway.  -- Or alternatively, 
probably just about any vendors compiler with all optimizations turned 
off will fullfill your requirements.

Again, why should everyone's C++ compiler have to generate slower,
more memory intensive code in order to meet the needs of people who
feel they want to maintain intimate control over their compiler?
Why can't they just buy a compiler that gives them that control?

>So what I'm trying to say is that we DO NEED to have some way of telling
>compilers "pack the last field of the parent class into the same word
>(if possible) as the first field of the derived class" but what we DON'T
>NEED is the current rule that allows the compiler to rearrange fields
>any way it pleases.

I disagree.  A common C++ hack I've seen in a number of libraries is
an attempt to inherit partial bit fields, so that a base class can
use a couple bits for flags, and subsequent derived classes can steal
a couple bits for their usages.  You can't do this with bit-fields right
now, and have to use macro/enum hacks instead.