🚀 go-pugleaf

In article <56638@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>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?

Perhaps you missed my point.  I was suggesting that the rule quoted above
be REVOKED and DELETED from the final ANSI standard.

>...  What percentage of C++ programmers need to diddle machine
>registers, and how often?

What percentage of C++ programmers *need* to use default parameters?  What
percentage of C++ programmers *need* to use multiple inheritance?

In the case of each of these language features a good case can be made that
0% of C++ programmers *need* these features.  Should we therefore chuck them
out of the language?  I think not.

The question really should be "How much harder would doing some reasonably
common programming task, X, be if feature (or constraint) F were ommited
from the language?" and also "How difficult is it for a typical implementor
to implement feature (or constraint) F?"

In the case of a constraint which would require compilers to maintain the
programmer-specified ordering of data fields, the implementation is trivially
easy.  (In fact, it is actually *harder* to do anything else!)  Also, the
usefulness of allowing the programmer to precisely specify his desired
field ordering is (in my opinion) quite large.  As I noted in a prior
posting, programmers may often need to do this when dealing with data
formats dictated by outside constraints (e.g. existing disk formats, existing
datacomm protocols, memory mapped I/O devices, and (last but not least)
layouts mandated by external routines (e.g. from libc.a) written in other
languages such as C).

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

Are you suggesting that it may be possible to generate more efficient
executable code if arbitrary field re-ordering (by the compiler) is allowed?
If so, are you prepared to give realistic (not contrived) examples of such
improvements?

If (on the other hand) you are only suggesting that a compiler could possibly
pack fields in some better order than I can, let me assure you that you are
wrong.  If you would care to organize a test, I'll be glad to pit my brain
against your compiler in a "structure packing" test any day of the week.
As a matter of fact, I surmize that the intelligence necessary to do good
structure packing is not even beyond the reach of your common garden slug.
This fact makes me all the more confused about your insistance that you
want compilers to do this for you.  Are you low-rating yourself? :-)

>... There continues to be a division between those 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.

You have made a rash generalization which is untrue.  I may be concerned with 
data formats (on disk or in a communications channel) and I may also be
concerned with portability.  Furthermore, I may even be diddling machine
registers and I may *still* be concerned with portability!!!  Obviously,
you have never seen any C code which drives some specialized peripherial
chip (e.g. an ethernet controller) which gets ported from one CPU to
another as that peripheral chips gets used in different kinds of systems.
I have seen this though.

Also, independent of the portability issue, there is also the issue of
"vendor independence".  Even if my code stays forever on this one system,
if I find a new compiler that I think generates better code, and I buy it
and install it and recompile my old code with it, I'd kinda like that old
code to continue working.  I don't want to see it start to core dump just
because compiler writers were given the freedom to rearrange my field
orderings willy-nilly and because they all choose to do it differently.

Right now, if I have the following C code:

	struct s {
		unsigned	field1:24;
		unsigned	field2:8;
	};

and this is in a program running on a 68000, I can get C compilers from at
least a dozen vendors that will lay this out *exactly* the same way.  Thus,
I have vendor independence.  That (and portability) are worth money to me.

Now I find out that I've lost this with C++, and I've gotten virtually
nothing in return. :-(

>... Or alternatively, 
>probably just about any vendors compiler with all optimizations turned 
>off will fullfill your requirements.

Not if it is not *required* by the standard!!!

>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?

Again, you have presented no evidence whatsoever that obeying the programmer's
wishes with regard to field ordering will result in slower (or "more memory
intensive") code in any real programs.  Until you do, this argument should
be viewed as simply a red herring.  I believe that this argument is bogus,
and that it has no basis in fact.  Programmers need not suffer any performance
penalty whatsoever in order to have the compiler obey their wishes.

-- 

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