Re^3 (was 2): struct comparison

R. Vuurboom roelof at idca.tds.PHILIPS.nl
Tue Jul 18 04:17:03 AEST 1989


In article <1989Jul15.210821.7950 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>
>For "char *" in particular, comparing the pointers themselves usually
>won't be what's wanted.  Of course, if the compiler wants to try to
>compare the chars, then it has to know whether the pointers really point
>to strings... and it doesn't.  Same problem with char arrays inside a
>struct -- is that a string (i.e. stuff past the NUL doesn't count) or not?
>
I might agree with your conclusion but I'm not too happy with your arguments.
Why should struct comparison be also supported for those structs with
member objects for which direct comparison support is not provided (arrays
and strings case in point - your example).

Now _if_ I were to define struct comparison it would _only_ be for
structs for which each member can be directly compared or
is a struct to which this requirement is recursively applied.
Something a compiler could figure out pretty easily in my opinion.
If you perchance attempt to compare two structs that don't satisfy above
the compiler could always bark at you. 
(Mind you, I only said _if_ :-)

I agree with Doug Gwyn though. Defining this would have been extending
the language and not just standardizing it. Perhaps Doug should go
ahead and post that list of arguments.

>Sigh, this one is pretty standard.  It's also dumb; do you then want to
>define struct add and subtract as well?  

Then he would have said so wouldn't he :-)

>It's also not a particularly good idea:  suppose I change to a polar 
>form, where the representation of a given
>complex number is not unique?  

Henry, this is cheating :-). If somebody comes along and changes the 
representation of an int while I'm not looking nobody expects the
two values (old representation vs new representation) to compare equal.

>
>To quote Dennis Ritchie:  "if you want PL/I, you know where to find it".

Where the sun don't shine? :-)
-- 
Its a thin red line between boring and borish.

Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof at idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof



More information about the Comp.std.c mailing list