struct comparison

[R. Vuurboom]

In article <2267 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
|
|I've seen no indication that it's sufficiently relevant *that it should
|be added to the language*; any definition of structure comparison would
|be peppered with caveats like "no unions" and "no arrays" and "it
|compares pointer values, not what they point to" and the like.
|

Ok, let me try and put my money where my mouth is:

Structure comparison is defined for structures which are recursively
derived from basic, enumerated, pointer or structure types. 

Two structs of the same derived type for which structure comparison
is defined compare equal if and only if each member (recursively) 
compares equal.


Which points out that in order to define something you don't
necessarily need to state what it isn't but just what it is.


|Yes, there have been cases I've seen where it might have been
|convenient, but I really *can* live with doing the member-by-member
|comparison myself.  

Agreed, so can I. I can live without struct assignment too but I kind of
like having it. 

I don't think the "living without" argument is really fair. We can all
live without a lot of things (probably even C :-). 

|And, given that there's no prior art, I agree with
|X3J11's decision to leave it out.  


Which makes me start wondering about volatile or - to go to another extreme -
const.

 

|If somebody sticks it into their
|compiler as an extension and we can really find out from experience
|whether enough people actually *would* use it enough to justify its
|existence, then it can be considered as an extension if it actually is
|used enough and doesn't confuse people.
|

The above I consider valid arguments, translating:

Is it relevant? viz. can you expect it to be used in "mainstream" programming?
Is it straightforward? Perhaps to put it another way: is it "natural".


|The original poster *did*, in fact, effectively ask "why isn't structure
|comparison in ANSI C"?  The question was answered, by Henry and others,
|and I have yet to see a *single* response to that answer that, to me,
|would justify the inclusion of such a feature *in the ANSI C standard*,
|given the lack of prior art (and yes, there *was* prior art for function
|prototypes, namely in C++; it may not have been in an otherwise "pure" C
|implementation, but at least it existed).  

Obviously I can't be sure that any particular argument will convince you
but this one might convince me:

enum make_t {BMW,PEUGEOUT,RENAULT,MERCEDES,...
enum colour_t {CHROMIUM_RED,CANARY_YELLOW,

typedef car
{
         make_t make;
	 colour_t colour;
}

...
	for( i=0; i < nr_cars_in_stock; i++ )
	{
		..
		if ( car_wanted == cars_in_stock[i] )

...

	
|I suspect *I* wouldn't use
|structure comparison if it were available to me in C; I'm almost certain
|I wouldn't use it if it were available to me in C++ - I'd define an "="
|operator for the data type, instead, and not be forced to rely on
|member-by-member comparison being the right answer.

The choice of whether you would want (need) to use abstract data typing
or data structure comparison is really quite clear cut. It is the cut
between whether the data structure represents an abstraction (complex
numbers case in point) or represents a combinatoric. In the first
case the object is _more_ than the sum of its parts. In the second case
the object _is_ the sum of its parts. A complex number has "more" meaning
than a pair of reals hence the extra operations needed to bring out this
meaning. A red car does not represent a higher abstraction level than the
concepts red and car considered separately. To put it simply, all applications
that use combinatoric objects (in the sense I've defined) could (and I
think would) use struct comparison.

In this particular application area struct comparison is both relevant and
straightforward.

Attempting to quantify how often this comes up and how often it needs to
come up to make into X3J11 is something I find impossible to do. All I
can say is that I have come across the above application area a number of
times.

-- 
I don't know what the question means, but the answer is yes...
(overheard on comp.lang.misc)
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof at idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof