Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!sdd.hp.com!decwrl!lll-winken!sun-barr!newstop!sundc!hadron!netxcom!elw From: elw@netxcom.DHL.COM (Edwin Wiles) Newsgroups: comp.std.c++ Subject: Re: "packed" objects Summary: Use of structures for writting data... Message-ID: <6815@netxcom.DHL.COM> Date: 1 Aug 90 22:44:54 GMT References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <6785@netxcom.DHL.COM> Organization: NetExpress Communications Inc,. Vienna, VA. Lines: 54 In an article jeremy@cs.ua.oz.au (Jeremy Webber) writes: >In an article ewiles@netxcom.DHL.COM (Edwin Wiles) writes: >> >> A) You would not be guaranteed that a data file written by a given >> program on one machine, would be readable by the same program compiled >> on a different machine under a different implementation of C++. >> (Assuming that hardware and byte ordering are the same, the order >> of structure/class elements wouldn't necessarily be the same.) > >The ability for a compiler to re-order the elements of structures/unions is a >useful optimization. Granted, it has it's uses. So I'm in favor of having a "packed" keyword which instructs the compiler to rearrainge the structures as appropriate, but against making such rearraingment the default. >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. 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. >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. >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. Later! Edwin.