greg@utcsri.UUCP (Gregory Smith) (04/09/86)
In article <2375@brl-smoke.ARPA> rbj%icst-cmr@smoke.UUCP writes: [ to compare structures ] s/x/ct/ >Secondly, struxures could be created with the padding bytes set to >all zero bits. Then, any garbage appearing in them could only be >creating by sloppy coding practices which even *I* abhor, even >considering my widely known nonportable tendencys. > > (Root Boy) Jim Cottrell <rbj@cmr> Garbage could also be created by correct and portable use of unions. A structure with holes could share a union with another hole-less structure, and filling in the hole-less one could stuff data into the holes of the holey one. Later stuffing of data into the holey struct would not clean the holes. Anyway, you are also saying that if I want an array of structs at run-time I must calloc() it rather than malloc()ing it, or my code *might* not work. If the struct is only, say, 4% holes ( not unreasonable ) this could be expensive ( admittedly the time might easily be made up by faster compares ). Two equivalent structs could also have different contents if they contained strings stored in char arrays: char a[30], say, and one contains "abcd\0\0\0..." and the other (re-used ) contains "abcd\0dribble\123foo_bar.." - of course, this can be avoided with strncpy, again at increased time cost. I don't think struct comparisons need be implemented. These are my reasons: (1) The above problems - you have to go through too much trouble to make it workable (2) Only compare for equality ( as opposed to ordering ) is possible. It is rare that you need to compare entire many-membered structs for equality. (3) Even if you do, the comparison is best done such that the first member to be compared is the one most likely to be different, and so forth. Only the programmer knows what this order is. The members could, of course, be ordered such that the first member is the 'best discriminator', etc, but this could force unnatural orderings. Also, in the string example above, if two strings were "foo\0\0....", they would be compared in their entirety, even though only the first 4 bytes are significant. (4) If you really need to do this, `struct foo's *a and *b can be compared by cmpmem( a, b, sizeof( struct foo )), where cmpmem is a memory-compare function. I agree it's not as nice as a simple *a==*b. There is the argument that something which is expensive should *look* expensive, which I feel applies to cars but not to programming languages. (5) A good argument for allowing compares is "Well, sure they're not often a good idea, but you don't *have* to use them." The only problem I have with this, is that you need a fairly deep understanding of what goes on in a machine before you can use them safely. And they *look* 'clean and simple' so that novices might have trouble. Also, modifications to a program containing struct compares might break the code in very obscure ways. In summary: I certainly don't consider the above a proof that struct compares shouldn't be implemented. However in my opinion, they aren't worth the trouble and the risk. -- "If you aren't making any mistakes, you aren't doing anything". ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg