🚀 go-pugleaf

In article <1029@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>Note that for:
>
>	extern void foobar (const int i);
>
>It can't make any difference to an optimizing compiler whether or not the
>const is in there or not, or whether or not foobar() enforces it strictly.

I disagree.  A compiler that uses a register passing protocol could
very well enregister a const int i before the call to foobar, expecting
that foobar would not molest it, and then attempt to reuse i without
re-enregistering it.

>>This is to say, the trick of casting to a non-const does not 
>>work on a parameter declared as "const."  Compilers can flag as an error 
>>these situations.
>
>Why so fascist?  I prefer warnings in such cases.

When a programmer writes a routine that plays games that are not portable, 
or may not work in the face of compiler optimizations, thus busting that
routine itself, I think that deserves a warning.

However, when a programmer writes a routine that appears to be correct by
inspection, appears to test out correctly, but in unusual situations can
bust the caller's code -- not the callee's code! -- then I think that
deserves an error.  The resulting bugs would be very insidious to try
to track down.

In article <1030@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>Use 'extern "C"' where an object needs backwards
>>compatibility to "C" packing order.
>
>Huh?

Just what it says.  Using 'extern "C"' around a class or structure 
definition will give you a structure that is compatible with your
C compiler [from the same vendor 1/2 :-]  Using 'extern "Pascal"' around
a class or structure definition will give you a structure that is
compatible with your Pascal compiler [from the same vendor 1/4 :-]
Otherwise, you'd not be gauranteed any backwards compatability between
the layout of a C++ class/structure, and a C or Pascal structure.

>>* Require current field ordering restrictions be maintained on things declared
>>"struct", but removed restrictions on anything declared "class."
>
>Bad idea.

I don't disagree, but state why you don't like this one so the rest of
us can follow your logic.

>>* Introduce an explicit keyword "packed" or similar.  Declaring a base class
>>"packed" turns off field ordering restrictions in that class and its 
>>derivatives, as well as representing a directive to the compiler that small
>>size is to be preferred to fast access.  Possibly vtable ptrs could also 
>>be replaced with smaller type tags in such classes....
>
>Since the issue involves the boundary between a derived class and exactly
>one of its base classes, I suggest that perhaps "packed" should be a way
>of doing inheritance, e.g.:
>
>	class doe : public rea, packed public me { ... };
>
>would specify that the earliest field of `doe' should get packed up against
>the latest field of `me'.

The problem is, the proposal intends not only to address the issue of
"packing up against" a base class, but also the possibility of 
"packing into" a base class.  Since "packing into" a base class might
require an explicit awareness in the base class not to mess with 
unused fields, the packed'ness needs to be declared in the base class.
Two choices then might be to make packed'ness a inherited attribute,
or to have to be redeclared in subsequent derived classes.  Seems to me
once a superclass has a packed attribute, the die has been cast,
any backwards compatibility is lost, and subsequent derived classes
should automatically follow their base class's packed or unpacked'ness.
Likewise, in MI having one base class packed would be enough to make
derived classes "packed."  "Packed" in this sense just means that C
packing rules are not necessarily being followed.

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.

In article <56632@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>...  I'd like to have comp.std.c++ be the forum
>for "public input" on the c++ standard.  This is the spirit in which
>I am writing to comp.std.c++

There is a way to get public input into the standard, but it is *not* to
post something here.  It is to write it down, on paper, and send it to
X3J16.  Yes, standards committees read proposals from Joe Random User.
Yes, they pay attention.  Yes, they even sometimes adopt them.  It helps
a whole lot if you have implemented and used your proposal; there is no
substitute for actual experience with language changes.  It also helps a
whole lot if it addresses some important need rather than being a cosmetic
change, given that X3J16's job is to standardize an *existing* language,
not invent a new one.  Regardless, it should be detailed and specific and
should nail down exactly what you want changed and what you want it changed
to:  do not expect someone on the committee to spend his time fleshing out
your proposal for you!  They spend enough time working on their own.

It is very likely that members of X3J16 read this newsgroup, but they will
probably consider it to be informal discussion, not a source of formal
proposals.  Translation, they can ignore anything they disagree with.

If you are seriously concerned, even about a single issue, it is not that
difficult or expensive to join a standards committee.  ANSI committees
are *required* to be open to all.  They tend to consist mostly of compiler
implementors, since it is very much in their interests to put substantial
money and manpower into participation, but anybody can join.  Best is to
actually attend meetings, but you can join as an "observer" and simply
get all the paperwork.  There will typically be a fee, perhaps $100/yr,
to cover reproduction and mailing costs.  If you want to actually do
justice to belonging, there will also be a *lot* of time involved, because
at regular intervals the postman delivers several pounds of paper for you
to read and comment on.  People who haven't tried it have no concept of
how tedious this is.
-- 
It is not possible to both understand  | Henry Spencer at U of Toronto Zoology
and appreciate Intel CPUs. -D.Wolfskill|  henry@zoo.toronto.edu   utzoo!henry

It seems that the discussion about packing currently needs some refinement
in the area of semantics.  I've always used 'packed' to mean that there is
no padding inserted into a struct (i.e. it's a WYSIWIG struct).  And,
'ordering' has always meant bit placement within a byte and byte placement
within a word.  So what seems to be under discussion here is really a
combination of packing and rearranging fields within a struct.

Both packing and ordering are highly desirable for the simple reason that
as the language (C/C++) stands now, it cannot deal *transparently* with the
real world.  This is due solely to the lack of rigor in the specification
for the definition of a struct - the compiler is allowed too much latitude
in the physical layout of a struct.

Your common intelligent programmable electric toaster device often (always?)
requires strange and arcane packing and bit fiddling to get data into and
out of the controlling interface.  Almost invariably, this results in
several routines to read in the data and stuff it into a structure, rather
than just reading it into the structure.  The same is true for many programs
that must import or export data.

If the language had constructs for specifying such things as packing and
ordering (bit, word, etc.), it could deal transparently with structures
created outside of its own venue and should result in code that is
both cleaner and more portable.

As far as the format of the extension goes, it should be a pure extension
and should not give new meaning to keywords currently in use.  If you
overload the current keywords, it is virtually guaranteed to break programs
that work fine as they are now.  This means that applying a special meaning
to 'extern' is a very bad idea.  It also means that default behavior must
conform to the current default - so any 'packing', 'ordering', or
'rearranging' extensions must be used explicitly in each place that they
are desired.

I admit that these thoughts are rather general, but hopefully they will
spawn another more concrete discussion. If not, I could always fire up the
old blow torch and start a jihad:  maybe something like, oh, say "cobol is
inherently better than C ..." :->.


- Tim Iverson
  uunet!xstor!iverson

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

In article <PCG.90Aug25160256@athene.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>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.

I think it would be best to let Bjarne speak for himself directly on this 
issue.  My impression is that his second book is carefully and deliberately
worded to allow wide latitude in the implementation of the language.

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

Certainly the fact that C++ is by far the most popular OOPL language has
something to do with it.  [I wouldn't call C++ "fashionable" though -- I'd
call it pragmatic.  Eiffel and Self would be the "fashionable" languages,
to my mind.]  But also the fact remains, if one really wants to write 
real world commercial OO software,  C++ is really the only language
up to the task. [IMHO]

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

Clearly I disagree with your assessment of Obj-C.  And C++.

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

I think you have this backwards.  In the absense of good optimizers, people
have to program around the limitations of their individual compilers, and
hand optimize code for a particular situation, keeping it from being
reusable.  I don't particularly like pragmas, but I think they may be an 
acceptable compromise to warn a compiler when people insist on writing hacks
that rightfully would fall outside the language.  Companies that design
portable compilers should tend to show a bias towards keeping the language
such that making portable compilers is easy.  Companies that design compilers
for a particular CPU or OS should tend to show a bias towards making the
language highly optimizable.  We should not be surprised if a tension 
between these two goals shows up as part of the standardization process.
[standard disclaimer]

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

Agreed.  But does such code actually party based on the layout of a particular
CPU's registers or ports?  -- I think not.

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

Hm.  I would think that now that C++ is the leading OOPL it needs to try
to meet the needs of the majority of its users.  I would not think that
the majority of people need or want to maintain intimate control of their
compiler.  I'd think the average OO programmer would be working on a much
higher level, using libraries others provide to do the bit twiddling.
Once these low level libraries are written, the many others can build on
these efforts.

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

If this opinion is correct, why would it not win in the marketplace?
Why cannot C++ programmers just say, hm, FuzzCo's Ultra-C++ compiler isn't
worth the time/size/money or complexity.  I'll just use this TinCo Tiny C++
compiler instead?  Whats wrong with letting the marketplace decide these
tradeoffs?  Why is it necessary to force your particular engineering 
design tradeoff beliefs into the language definition itself?

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

Actually, my conclusion is not that compilers may reorder at will.  My
conclusion is that compiler designers should have the freedom to decide
these issues for themselves, and that C++ programmers should have the
freedom to choose the compiler that then best serve their needs.
Nothing I have proposed forces a vendor to offer a large, complicated 
compiler.

Again, compilers already have the right to almost completely reorder a 
structure at will.  The *only* constraint in E&S is that within a labeled
section, member variables declared later will be places at "higher" addresses.
The reason given for this constraint is backwards C compatibility.  Well,
the constraint is so weak as to offer little in backwards C compatibility.
So my suggestion is to remove it, or to relegate it to those features of
the language specifically addressing backwards compatibility.  To my eye,
having both the extern "C" construct, and a separate field ordering 
restriction applied accross the language, looks like a simple historical
oversight, that should be fixed.

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

Then don't buy or use such compilers.  Use one that suits your fancy.
I don't propose to try to force a compiler you don't like on you.
Why do you want to force your particular compiler design beliefs onto
the compiler I would use?  Again, my proposal is to leave this issues
to the sensibilities of the compiler designers, and the power of the 
marketplace.  Over the near term, I'd be very surprised if any compiler
diverges too far from the cfront object model, because the cfront object
model represents the only object model that many programmers know. So there
would be great market skepticism to a compiler that introduced a very 
different object model.  However, as time goes on, other OOPLs are going
to demonstrate very different object models, and I claim we want C++ to
be specified with the freedom to allow compilers to incorporate the best
of those new object models.  And/or to allow C++ compilers be designed
simply to allow compatibility to these other object models.

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

I guess from my perspective, there is clearly not one answer to this question.
The tradeoff between development costs verses runtime costs is very much
a function of the number of units of your program you intend to produce.
If only a couple copies of a program are to be created, development cost
is paramount, and runtime cost is typically unimportant.  If a company
makes millions of copies of a programmer however, runtime costs outweight
all other factors.  A company that failed to shave the last few seconds
from their software in that situation would be costing society thousands,
if not millions of dollars in wasted user productivity.

In the first scenerio, a C++ programmer might want to use an p-coded
C++ implementation that follows a minimal recompilation strategy.  This
might be accomplished by inheriting via reference, not embedding objects,
and tagging any newly declared members on the end of an objects' section.
This is one object model totally different than the cfront model.

In the second scenerio, a highly optimizing compiler might be used.  Pragmas
might be used to indicate when constants aren't.  Pragmas might be used to
indicate when a class is a leaf class.  Compilations might be optimized on
a module global basis.  Smart linkers might winnow out vtable indirect calls.
Fat tables, or tricks might be used.  Fields might be reorganized based
on profiling information.  This would also lead to an object model very
different from cfront.

Thus, I don't believe one object model spans the needs of all C++ users
[nor all systems C++ might run on -- such as a Rekursiv-like machine,
or a Lisp-like machine, or a Smalltalk-like machine]  So I believe it 
would be very short sighted to try to specify the C++ language strictly
around a cfront-like object model.  Let's leave our options for the future
open.