🚀 go-pugleaf

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