Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!bert.llnl.gov!howell From: howell@bert.llnl.gov (Louis Howell) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: Message-ID: <1990Aug27.152540@bert.llnl.gov> Date: 27 Aug 90 22:25:40 GMT References: <1070@lupine.NCD.COM> <259400004@inmet> <56940@microsoft.UUCP> <1990Aug27.212649.16101@csc.ti.com> Sender: usenet@lll-winken.LLNL.GOV Reply-To: howell@bert.llnl.gov (Louis Howell) Organization: Lawrence Livermore National Laboratory Lines: 41 In article <1990Aug27.212649.16101@csc.ti.com>, peterson@csc.ti.com (Bob Peterson) writes: |> [...] |> 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 [...] I don't buy this. The representation of objects within a program should have nothing to do with the representation of those objects within files. If an object needs a read/write capability, the OODB developer should write explicit input and output functions for that class, thus taking direct control of the ordering of class members within a file. For a large database this is desirable anyway, since even in C the compiler is permitted to leave space between members of a struct, and you would not want to store this padding for every object in a file. I really don't see why reordering of fields in C++ is any worse than the padding between fields which already existed in C. Both make the binary layout of a struct implementation-dependent. I can sympathise with those who occasionally want direct control over member arrangement, and it might be nice to provide some kind of user override to give them the control they need, but such control never really existed in an absolute sense even in C. It certainly should not be the default, since most users never need to worry about this type of detail. Louis Howell #include