Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!yale!mintaka!snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!ncrlnk!ncr-mpd!Chuck.Phillips From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) Newsgroups: comp.std.c++ Subject: Re: "packed" objects Message-ID: Date: 1 Aug 90 08:05:47 GMT References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <6785@netxcom.DHL.COM> Sender: uucp@ncr-mpd.FtCollins Organization: NCR Microelectronics, Ft. Collins, CO Lines: 38 In-reply-to: jeremy@cs.ua.oz.au's message of 31 Jul 90 23:13:11 GMT >>>>> On 31 Jul 90 23:13:11 GMT, jeremy@cs.ua.oz.au (Jeremy Webber) said: Jeremy> The ability for a compiler to re-order the elements of Jeremy> structures/unions is a useful optimization. I would argue that any Jeremy> code which writes structures to a data file is non-portable. True. Even if the ordering is identical, the alignment may vary. However, alignment is not _likely_ to vary between systems using the same CPU, although it still _can_ vary due to compiler differences. Jeremy> If data is to be portable it should *always* be written element by Jeremy> element, preferably in ASCII. If your program isn't already I/O bound, this is an excellent strategy, and I highly recommend it as the default strategy. Jeremy> The programmer should never assume specific structure ordering, Jeremy> except in the case of bit field specifications, which can override Jeremy> the compiler's defaults. Even this can fail, unless all the world is a 32 bit int. Seriously, many programs have to bang hardware which may not pack data in the "optimized" form. Perhaps this (and portability between compilers) is partly why order of inheiritance became defined under C++ 2.0. I also suspect reordering members between parents in a derived class such that their elements are interleaved, would present a run time nightmare for the C++ implementor. Perhaps one of the implementors out there would care to comment. Jeremy> This is the sort of hackery which causes many C programs to fail! ...and many operating systems to work. #pragma STD_DISCLAIMER -- Chuck Phillips MS440 NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp