Path: utzoo!attcan!uunet!samsung!usc!wuarchive!mailrus!news-server.csri.toronto.edu!utgpu!watserv1!watmath!watmsg!gjditchfield From: gjditchfield@watmsg.uwaterloo.ca (Glen Ditchfield) Newsgroups: comp.std.c++ Subject: Re: "packed" objects Message-ID: <1990Aug2.142410.10541@watmath.waterloo.edu> Date: 2 Aug 90 14:24:10 GMT References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <6785@netxcom.DHL.COM> <6786@netxcom.DHL.COM> Sender: daemon@watmath.waterloo.edu (Owner of Many System Processes) Organization: University of Waterloo Lines: 24 In article meissner@osf.org (Michael Meissner) writes: >Also, it would seem to me that reordering things across class >boundaries is a really bad idea -- then subclassing and virtual >functions would have no chance of working. In article mcgrath@paris.Berkeley.EDU (Roland McGrath) writes: >If it is not feasible to reorder members across class boundaries and still do >subclassing and virtual functions right then no one will try to do it in their >implementation. That doesn't mean the standard should prevent people from >trying if they want to. Reordering does not have to go so far as to change the offsets of inherited members. The rule could be that new members can be placed in holes left by padding in the superclass or in unused portions of storage units that contain inherited bitfields. I think this would do all the packing that Jim Adcock originally wanted, without affecting current implementations of inheritance. Since nothing in C corresponds to class inheritance, I don't see that this introduces any incompatibility, either. If you declare a struct, it would be laid out just like a C struct. Glen Ditchfield gjditchfield@violet.uwaterloo.ca Office: DC 2517 Dept. of Computer Science, U of Waterloo, Waterloo, Ontario, Canada, N2L 3G1 These opinions have not been tested on animals.