Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: Randomly ordered fields !?!? (Was:
Message-ID: <57009@microsoft.UUCP>
Date: 28 Aug 90 18:19:40 GMT
References: <1070@lupine.NCD.COM> <259400004@inmet> <56940@microsoft.UUCP> <1990Aug27.212649.16101@csc.ti.com>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 23

In article <1990Aug27.212649.16101@csc.ti.com> peterson@csc.ti.com (Bob Peterson) writes:
>  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.

Hm, I thought that OODBs were addressing this issue already.  If one has
software that is going to be used for a number of years, object formats
are going to change -- if not by automatic compiler intervention, then
by programmer manual intervention.  OODBs have to be designed to allow
for the evolution of the schemes used in the software, and the corresponding
object layouts.  Compilers have always hid field layouts from users --
details of packing have never been exposed.  If some other tool, like an
OODB needs to know these details, traditionally they are made available
via auxiliary files or information the compiler generates, such as debugging
information.  If your OODB strategy insists that the layout of objects
not change from now to eternity, then I don't understand how you can have
a reasonable software maintainance task.