🚀 go-pugleaf

In article <1229@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:

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

I disagree.  I don't see why difficulty of implementation should be an issue in
the language standard.  It's not a list of implementation guidelines; it's a
standard for how the language behaves.  You seem to presume that the people
contributing to the standard will be at least as clever as any implementor of
the language.  I find this a completely ridiculous presumption.  Just because
you can't think of a way to do something, you want to disallow others from
attempting it.  I can't think of a way to do it either, but I would fight the
the right of others to make the attempt.

   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!)

So obviously lazy implementors will do what you want, and clever/hardworking
implementors will do something more.

   Also, the usefulness of allowing the programmer to precisely specify his
   desired field ordering is (in my opinion) quite large.

Although I think I consider this less useful than you do, I am in favor of
retaining a way to force a given field order.  Using:

extern "C"
{
  struct foo
    {
      char elt0;
      int elt1;
    };
}

does this quite well.

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

Indeed true.  This is why I advocate giving them a way to do so, shown above.

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

I'm not so prepared.  Are you prepared to prove it impossible?

   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.

Given that all present compilers are bound by the present rules, this idea is
somewhat ridiculous.  I expect the standard to outlive present or near-future
implementations, however.  Otherwise, what's the point of having a standard?

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

Where do you find these garden slugs with absolute prescience of all possible
future computer architectures and C++ implementations?

   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.

This is an excellent example.  Since we are speaking of C++, and the example is
C code, you can simply put it within `extern "C"' and have all the guarantees
you now have with the C code.

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

You have not lost this functionality.  You simply must use a slightly different
construct.  Since you are using a significantly different language, you should
consider yourself lucky that the necessary change is so minor.

By my standards, the possibility of many new optimizations as yet unconceived
of is not "virtually nothing".

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

Quite true.  An excellent argument for why field reordering should not be
allowed within `extern "C"'.

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

You again presume foreknowledge of all possible future implementations.  I find
such arrogance surprising from an otherwise reasonable person.

   I believe that this argument is bogus, and that it has no basis in fact.

I consider it a fact that some C++ compiler implementor may in the future come
up with a way to improve efficiency through field reordering.  Until such a way
is proven impossible, this remains a fact.

   Programmers need not suffer any performance penalty whatsoever in order to
   have the compiler obey their wishes.

This is true if and only if your definition of "performance" includes only
run-time program speed.  While this type of performance is of great concern to
me, of equal concern is programmer performance.  Programmer performance
degrades greatly when the programmer is forced by constraints of the language
to do work that the compiler could be doing.
--
	Roland McGrath
	Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland