In article <MCGRATH.90Aug3011745@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes:
>   It is currently a defined property of C++ (see E&S) that any program which
>   is both legal C and legal C++ means the same in both...
>
>I don't see how this would not remain true if member reordering were allowed.

The problem is that in C, the ordering is a documented property of the
language *and programs are therefore allowed to depend on it*.  For
example, it is explicitly guaranteed that a pointer to a later member
compares high against a pointer to an earlier one, and there are probably
programs out there somewhere that need this.  Such a program will break,
despite being legal C, if compiled with a reordering C++ compiler.
--
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry

I'm not suggesting codifying practice that does not yet exist.

I'm merely suggesting not prohibiting it.
--
 Roland McGrath
 Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

In article <1990Aug2.165111.25529@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
   It is currently a defined property of C++ (see E&S) that any program which
   is both legal C and legal C++ means the same in both (with a couple of tiny
   and hard-to-avoid exceptions).  Many people think that this limited upward
   compatibility is a good idea and should not be sacrificed.  The name of
   the language is "C++", not "D".

I don't see how this would not remain true if member reordering were allowed.
The C compiler will generate accesses to the structure in the given order
throughout the program, so all the accesses will work.  The C++ compiler will
generate accesses to the structure in whatever order it deems appropriate,
using this single order throughout the program, so all the accesses will work.

You can't expect to interlink different pieces of a program that is both legal
C and legal C++, some of which are compiled in C, some in C++, anyway.  If you
could, `extern "C"' would not have been invented.
--
 Roland McGrath
 Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

In article <MCGRATH.90Aug1225852@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes:
>... However, we are talking about the standard for C++.  As this standard
>remains to be defined, and is independent from the existing standard for C,
>I don't see the relavence of your statement.

It is currently a defined property of C++ (see E&S) that any program which
is both legal C and legal C++ means the same in both (with a couple of tiny
and hard-to-avoid exceptions).  Many people think that this limited upward
compatibility is a good idea and should not be sacrificed.  The name of
the language is "C++", not "D".

On a related point, people should bear in mind that the best language
standards are the ones that codify *existing practice*, as opposed to
throwing in every wild and wonderful feature that somebody thought was
a good idea.  X3J11 did, by and large, a very good job on this for C.
(If you want to see what happens when standards committees start trying
to invent the language, look at ANSI BASIC or FORTRAN 9x.)  If the C++
standards effort does its job properly, ranting on the net about the
vital need for your favorite feature will be entirely futile.  What
you need is an implementation of it and some favorable experience using
that implementation, followed by a formal proposal to the committee (no,
posting it to the net does not qualify).
--
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry