🚀 go-pugleaf

On 16 Aug 90 19:20:16 GMT, jimad@microsoft.UUCP (Jim ADCOCK) said:

jimad> Actually, the will of this programmer is that C++ compilers generate the
jimad> fastest and most compact code possible from my class declarations.  It 
jimad> is not C++ compilers that are tharting this will, but rather people who
jimad> want to continue using C++ as a C assembly language.

These include Stroustrup, apparently. See the introduction to his first
C++ book... C++ *has been designed* as an OO MOHLL/SIL.

jimad> I want to be able to use C++ as a fast, efficient object oriented
jimad> language.  This requires compilers that have great optimization,
jimad> and great freedom to optimize.

Why don't you use Self? Objective C or Eiffel? Just because C++ is
fashionable?

IMNHO C++ is just about the only OO around with widely available
compilers designed as a SIL/MOHLL . Let's keep it that way. People who
want a more applications oriented language should choose something like
one of the languages above. As soon as GNU CC 2.0 will be released I
think that Objective C will grow very much in popularity, IMNHO.

jimad> There continues this division between C/C++ people who want a compiler
jimad> to "do what I say" verses "do you best optimizations."  I think this
jimad> issue should be addressed in the marketplace -- not in the language.

This of course kills any idea of portability. You programs start to have
semantics that depend, by construction, both on the compiler and the
language. This is IMNHO *very* bad, vide the abominable pragma pandora
box of Ada and Ansi C. It may be very good for compiler vendors, though,
especially those that have or think will have a large market share, and
want to get entrenched into it. Thank goodness AT&T does not reason that
way, because they are too large and diverse an organization themselves.

jimad> If you want to use C++ to play with machine registers, then
jimad> portability is not an issue to you anyway.

Ah no, not so easy. One can provide, thanks to the wonders of separate
compilation or conditional preprocessing, both a slow portable version
and a fast one that will not work on every implementation, but is still
expressed as much as possible in the base language.

jimad> Again, why should everyone's C++ compiler have to generate slower,
jimad> more memory intensive code in order to meet the needs of people who
jimad> feel they want to maintain intimate control over their compiler?

Maybe because the language has been designed for the latter group...

And because many times the compiler cannot understand the program better
than they do anyhow, or requiring the compiler to do it is not a win-win
situation, e.g. results in larger, slower, less reliable compilers.

A language _definition_ should be independent of compiler implementation
issues, but the language _design_ should well take into account such
pragmatics. "advanced" features are easily botched; consider Ansi C and
'volatile', whose _omission_ makes a program undetectably erroneous, and
that otherwise exists almost only to assist the optimizer. This
particular problem does not apply to field reordering. There is another
problem though: that it makes the binary output of programs compiled
with different compilers or releases of the same compiler potentially
incompatible. Do we really want to force using XDR or ASN.1 throughout?

Consider also the conclusion that you and Guilmette seem to be reaching:
the compiler may reorder at will by default, as long as there is some
mechanism to override it. This seems the best solution, as long as you
do not see the additional cost in complexity/unreliability of the
manual, of the compiler, of the program build process. You have to weigh
these things carefully, and if you do not, you go down the slippery path
Ansi C has gone.

So, are today's C/C++ multimegabyte compilers significantly more
reliable and faster and generate better quality code than those that run
in 64KB[+64KB]? IMNHO no, or at least not enough that the changed
pragmatics should influence for design of the language (as has happened,
for the worst, with Ansi C).

But maybe I am wrong, and the relative cost of compile time resources
(time, space, programmer confusion, reliability) vs.  runtime speed have
changed so much that a modest increase of the latter can be economically
bought at the price of a large increase of the former.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk