Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!csc.ti.com!ti-csl!m2.csc.ti.com!peterson
From: peterson@csc.ti.com (Bob Peterson)
Newsgroups: comp.std.c++
Subject: Re: Randomly ordered fields !?!? (Was:
Message-ID: <1990Aug27.212649.16101@csc.ti.com>
Date: 27 Aug 90 21:26:49 GMT
References: <1070@lupine.NCD.COM> <259400004@inmet> <56940@microsoft.UUCP>
Organization: TI Computer Science Center, Dallas
Lines: 59

In article <56940@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>       ...
>                       Or are you proposing that the rules should be
>changed to prevent compilers from reordering?  The only restriction
>right now is that within a labeled section fields must be at increasing
>addresses.  Which neither requires nor prevents compilers from changing
>field orderings from your expectations, but rather leaves those decisions
>to the sensibilities of the compiler vendor.  If some future C++ compiler
>supported persistence and schema evolution, would you then demand a
>user specified field ordering?

  A frequently stated goal of object-oriented database (OODB) systems
developers is to support storage of objects over long periods of time
and concurrent access to the OODB by concurrently executing programs.
This implies that an object stored several years ago be fetched today. 
This, in turn, implies that the OODB support evolution of a stored
object, should the definition of that object change.  Sharing implies
that different applications may request access to the same object at
roughly the same time.

  If a C++ compiler is able to reorder the fields of an object at will,
the object evolution problem faced by OODB developers is substantially
more complex than if field reordering is restricted.  Not only can an
object definition change as a result of an explicit user action, but
simply because the user has upgraded to a new version of the compiler
or added a compiler from a different vendor.  Requiring a recompilation
of the all programs may solve the problem for programs that don't save
objects.  However, for environments in which objects are retained for
substantial periods of time, or where objects are shared among
concurrently executing program compiled with compilers using different
ordering rules, a recompilation requirement doesn't seem a viable
solution, IMHO.

  In this organization there are pieces of some programs too big to
compile with cfront 2.1 and Sun's C compiler.  We use g++ for these
programs.  Other parts of the system don't require use of g++.  I would
like to think that different pieces of this system would be able to
access the OODB without incurring the performance penalty of converting
the stored data based not only on machine architecture but based on
which compiler is in use. At the very least, this is an additional, and
in my opinion unnecessary, constraint.

  If C++ standard continues to specify that, by default, fields can be
reordered, the standard should also require that the rules governing
such reordering be made explicit and public.  An additional requirement
I'd like to see is that a conforming compiler have available a warning
stating that reordering is happening.  If these two requirements are
included OODB vendors, as well as applications that write objects as
objects, would have some hope of understanding what a compiler is
doing.  Allowing compiler vendors to hide such details will be costly
in the long term.

    Bob

-- 
   Hardcopy    and       Electronic Addresses:        Office:
Bob Peterson           Compuserve: 70235,326          NB 2nd Floor CSC Aisle C3
P.O. Box 861686        Usenet: peterson@csc.ti.com
Plano, Tx USA 75086    (214) 995-6080 (work) or (214) 596-3720 (ans. machine)