roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (07/18/89)
In article <1989Jul15.210821.7950@utzoo.uucp> henry@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@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof
diamond@diamond.csl.sony.junet (Norman Diamond) (07/19/89)
In article <167@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes: >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 - [Henry Spencer's] example). Maybe for the same reason structs can be passed as function parameters and be returned as results even when some member objects do not have direct assignment support (arrays and strings for example). C-90 (maybe C-89 if they're quick) did define a lot more new practices than is admitted by Doug Gwyn. C-0x will define many more. C-0x will be called C, not D; just as C-90 is still called C. So this newsgroup is in fact an appropriate place for this kind of discussion. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.
donn@hpfcdc.HP.COM (Donn Terry) (07/24/89)
Personal opinion: Omitting comparison of at least a limited range of structs presents a class of problems that has not been addressed here so far. There are certain predefined types in classical UN*X (and probably other OSs as well) that would "like" to be structs (or at least objects larger than long). dev_t is a good example. For historical reasons, usually associated with comparisons on such types, they must be constrained to integral (or at least arithmetic) types. Because ANSI C prohibits comparisons on such larger types, standardizers of other things (e.g. POSIX) are constrained: 1) require integral/arithmetic types, and force unnatural kluges on some OS's (more than 32-bits worth of I/O addressability, allowing for type modifiers: try to cram it into an dev_t or force an otherwise unneeded long long long long... type). 2) Define new types for the standard, and define operations on those types for all relevant operations. (Typically at least 3: comparison, and some modifier and it's converse.) 3) Break existing applications by permitting/requiring struct types that will break the applications that use the object. If ANSI C had permitted even a strongly constrained comparable struct type these problems would have been eliminated. (E.g. add "comparable" struct to the language: compilers would be permitted to reorder to allow comparison as a byte-by-byte comparison; possibly prohibit pointers, possibly prohibit or constrain unions.) Even off_t would have been helped, as only the add and subtract operators would have to be macros were this possible. Those are not _too_ common. (Something has to give with off_t, and soon; 4Gb disks are coming along very soon. It would be nice to find a way to deal with them without having to rewrite every use of off_t and lseek() in the world. The ANSI C solution might work (I forget the names, but there is a solution for stdio), but it does require a lot of rewrite of existing applications.) Donn Terry HP Ft. Collins Chair 1003.1 (and speaking only for himself)
decot@hpisod2.HP.COM (Dave Decot) (07/25/89)
I really don't see any problem with a definition of structure comparison that said two comparable structures match if and only if the corresponding elements compare equal. If an implementation wants to make holes in structures, that's fine; it just has to deal with avoiding the holes when generating code to compare the structures. An application wishing to compare strucutres (or things which are potentially structures) should be willing to put up with a little delay. Or, if it's smart enough to notice that the particular structures involved are never modified via aliases, the compiler could initialize them with 0's in the holes and not worry about them when comparing. As Donn Terry points out, most of the structures one wants to compare in practice have no holes, anyway. Dave
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/25/89)
In article <12040019@hpfcdc.HP.COM> donn@hpfcdc.HP.COM (Donn Terry) writes: >(Something has to give with off_t, and soon; 4Gb disks are coming along >very soon. It would be nice to find a way to deal with them without >having to rewrite every use of off_t and lseek() in the world. The >ANSI C solution might work (I forget the names, but there is a solution >for stdio), but it does require a lot of rewrite of existing applications.) The natural and efficient representation for fpos_t (the generalization of off_t) in virtually any large-system environment would be such that special arithmetic is required to maintain properly normalized (block, byte) information. If unnormalized arithmetic is allowed, then you need a special normalizing comparison operation. It's considerations like these that convinced many of us that the gain in supporting more extensive structure operations directly in the language would not be worth the trouble.
pardo@june.cs.washington.edu (David Keppel) (07/25/89)
>[Ongoing discussion of struct comparison]
I think that the discussion of structure operators has moved out of
the charter of the comp.std.c newsgroup (until the next ANSI
committee meeting :-).
Please follow up to comp.lang.c and/or comp.lang.misc.
;-D on ( Structure isolationism ) Pardo
--
pardo@cs.washington.edu
{rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardodiamond@csl.sony.co.jp (Norman Diamond) (07/26/89)
In article <12040019@hpfcdc.HP.COM> donn@hpfcdc.HP.COM (Donn Terry) writes: >(Something has to give with off_t, and soon; 4Gb disks are coming along >very soon. It would be nice to find a way to deal with them without >having to rewrite every use of off_t and lseek() in the world. It is time to learn a lesson from the 80*86 family. Near and far are kluges. It is a pain in the *** to be unable to do pointer arithmetic in a reasonable fashion. The lesson? Integral types and off_t will be kluges. It will be a pain in the *** to be unable to do off_t arithmetic in a reasonable fashion. Any vendor who supplies 4Gb disks should supply a long long type in their C compilers. Quality of implementation issues should encourage this semi-portable extension. This will save many pains in the ***. If the marketplace allows this to occur, then C-0X will standardize it. -- -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.