Path: utzoo!utgpu!watmath!att!cbnewsc!nevin1
From: nevin1@cbnewsc.ATT.COM (nevin.j.liber)
Newsgroups: comp.std.c
Subject: Re: struct comparison
Message-ID: <2092@cbnewsc.ATT.COM>
Date: 28 Jul 89 02:57:21 GMT
References: <2874@solo3.cs.vu.nl> <1989Jul14.155312.2063@utzoo.uucp> <2878@kappl.cs.vu.nl> <1989Jul15.210821.7950@utzoo.uucp> <167@ssp1.idca.tds.philips.nl> <1989Jul18.020424.2392@utzoo.uucp> <2335@trantor.harris-atd.com> <2261@auspex.auspex.com> <171@ssp <2267@auspe
Reply-To: nevin1@ihlpb.ATT.COM (nevin.j.liber)
Organization: AT&T Bell Laboratories
Lines: 58

In article <2410@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Badger BA 64810) writes:

>When I entered this discussion, it was centering on whether struct comparison
>was a well-defined and useful operation.  I think that has been established
>for structs not containing unions.  Whether to add it to the language --
>in particular whether to include it in ANSI C -- is another, more 
>(mostly?) political question.  

It is NOT mostly a political question!  There are problems that would
be introduced with it!  Consider the following scenario:

Jane Programmer, fresh out of college, reads all about C with the
struct equality extension (C-SEE :-)), and is raring to go program
with it.  She, along with her colleages, write 10,000,000 lines of code
in C-SEE.  An example of a struct used in this code (and there are
thousands) is:

	struct typical
	{
		int	foo;
			/* ... hundreds of variables */
		char	bar;
	}

Three years later, you come on the scene.  Your boss asks you to make
some enhancements to the ten million line program, and one of them requires
you to change struct typical (among other things).  Now it looks like:

	struct typical
	{
		int	foo;
			/* ... hundreds of variables */
		char	bar;
		short	uh_oh;
	}

Guess what happens?  The code breaks!!  By seemingly innocently adding
a field to the struct, you now have to go through and fix all the code
you broke.  If you are lucky, and you remembered to do this before you
sent the code to the testers, you could get the compiler to find all
the instances of the struct (by simply adding a union to the struct
typical definition, and having the compiler give you the error lines),
but that isn't the point.

Also, how do you plan on fixing the code?  Are you going to think about
each and every struct comparison, and decide on-the-spot whether or not
the rewrite it the way you would in standard C (if a union was added to
typical, you would *have* to rewrite ALL the C-SEE dependent stuff)?


The only situation where the C-SEE extension would be useful is when
you know that you just want to compare all the elements of the struct
together.  In order to do this, you can't abstract over the struct; you
have to *know* what each element is in order to use C-SEE safely.  It
is better self-documentation, as well as safer, to just write out the
member comparisions longhand.
-- 
NEVIN ":-)" LIBER  AT&T Bell Laboratories  nevin1@ihlpb.ATT.COM  (312) 979-4751