🚀 go-pugleaf

In article <56268@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>Proposed:
>>
>>We need a way to "pack" objects over inheritence boundaries, and possibly
>>between labeled fields of a declaration.  I do not propose here exactly
>>what the "right" way to do this is.
>
>I should clarify that I was not proposing that every compiler actually has
>to do the packing, nor that there need to be a standard way to do that 
>packing.  What I was proposing is that we need a way to turn off the standard
>C++ field ordering restrictions, such that a compiler can choose to lay out
>those fields in any order it feels is appropriate.  Perhaps the easiest way 
>to accomplish this is just throw away the traditional restrictions on field
>ordering.

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)".

Therefore, the members of the following type, may legally be laid out in
*any* arbitrary ordering by a "standard conforming" compiler.

	struct S {
		int f1:22;
	public:
		int f2:10;
	public:
		int f3:3;
	public:
		int f4:5;
	public:
		char f5;
	public:
		short f6;
	};

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!

(I tried to point out this problem here once before, but either nobody was
listening or else nobody was cared).

I am *not* in the camp that believes that the compiler should be given even
more leway to mess around with my intentions, and to change my intended
meaning.  Quite the opposite.

I'm a big boy now.  I can establish a good and proper ordering for the data
members within my structs and classes all by myself, and without any help
from the compiler, thank you.  In fact I would *prefer* to do it myself,
because I believe that it is far more likely that I will understand where
things out to go (or must go) than the compiler will.

Consider the following:

	class C {
		unsigned private_member_1:22;
	public:
		unsigned public_member_2:10;
	private:
		unsigned private_member_3:7;
	public:
		unsigned public_member_4:25;

		C ();
		// ... other member functions
	};

Now I wrote the fields in the order shown so that they would fit perfectly
into two words *only* as long as they are actually allocated in the order
shown.  Unfortunately, the rule cited above allows "standard conforming"
compilers to thwart my intentions and to reorder the fields in any damn
order they please.

The implication is that I simply cannot make use of access specifiers (and
the benefits they can provide) for any class or struct where field ordering
is critical (either for reasons of space economy or because I am dealing
with some hardware-defined layout, such as commonly arises in cases of
memory-mapped I/O devices with multiple control/data registers).

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.

These issue are mostly separate, until you see that the achievment of
"good" packing between a base class and a derived class may depend upon
the ability of the programmer to force a particular (packable) field
to be allocated *last* within a struct or class.

Right now, if you want to (or need to) use access-specifiers within the
base class, it is IMPOSSIBLE select (or to force) the proper allocation.



-- 
// Ron Guilmette
// C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.