Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!decwrl!ucbvax!pasteur!paris.Berkeley.EDU!mcgrath From: mcgrath@paris.Berkeley.EDU (Roland McGrath) Newsgroups: comp.std.c++ Subject: Re: "packed" objects Message-ID: Date: 2 Aug 90 05:58:52 GMT References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <6785@netxcom.DHL.COM> <6815@netxcom.DHL.COM> Sender: news@pasteur.Berkeley.EDU Organization: Hackers Anonymous International, Ltd., Inc. (Applications welcome) Lines: 57 In-reply-to: elw@netxcom.DHL.COM's message of 1 Aug 90 22:44:54 GMT In article <6815@netxcom.DHL.COM> elw@netxcom.DHL.COM (Edwin Wiles) writes: >I would argue that any code which writes structures to a data file is >non-portable. If data is to be portable it should *always* be written >element by element, preferably in ASCII. I work in the real world (presumably you do too), and in the real world you don't always have enough file space to store data in 'ascii' format. (And you can't always "throw hardware at the problem" either!) Nor do you have the time that is required to write and debug thirty or more 'read/write' statements for every one of your data structures. THAT is wasted effort. Far quicker and simpler to write the data structure itself out. Fine. Do it. Just don't expect the data files to be portable. That's all. Unfortunately, although I use C++ on my home computer, I haven't been able to convince work to switch over, and even when I do, they will NOT allocate the time required to rewrite all the old code. This means that when/if we switch to C++ for our new code, the data it writes MUST be compatible with the existing code, who's data files ARE portable to a number of machines, and which DOES use structures for reading and writting data. As I said, this is why we have `extern "C"'. If certain structures need to be done compatibly, declare them inside `extern "C"', and they will be done just as the C compiler does them (not that this gives you any measure of portability across different machines, operating systems, compilers, or compilation-time command-line flags). >The programmer should never >assume specific structure ordering, except in the case of bit field >specifications, which can override the compiler's defaults. Now that is just sooo much malarky. No C compiler that I know of rearranges the order of elements in a structure. Some of them adjust to 2 byte boundaries, and some to 4, due to hardware considerations, but NONE of them change the order of the data as specified by the source. Well, good! Then when you make your strucutre declarations inside `extern "C"' you won't have any problems. Outside of `extern "C"', we're talking about a different language, however. >This is the sort of hackery which causes many C programs to fail! Never done it to me! If it has to you, then I suggest that there are compiler writers out there who are puting in "features" which are most definitely non-standard. Any non-standard feature should NOT be the default but should instead be used only by the express wish of the user. Agreed. However, we are talking about the standard for C++. As this standard remains to be defined, and is independent from the existing standard for C, I don't see the relavence of your statement. -- Roland McGrath Free Software Foundation, Inc. roland@ai.mit.edu, uunet!ai.mit.edu!roland