maart@cs.vu.nl (Maarten Litmaath) (07/21/89)
It seems I'm not the only one in favor of (a limited form of) struct
comparison. On my `traditional struct complex' example
struct complex {
int Re;
int Im;
} z, w;
...
if (z == w) ...
Henry Spencer wrote something like
"Then how about struct addition, sonny?"
to which I say
"Yes! Another useful struct operation!"
Of course the structure elements must be addable, i.e. no pointers etc..
(There we go again, Blair!)
Arrays would be added member-wise. Hmm, sounds interesting...
Another point raised by Henry
"How about polar representation of complex numbers and
non-uniqueness?"
was nicely dealt with by Roelof Vuurboom. Mathematical problems caused by
(inadequate) representation of mathematical quantities, and language
definitions are two different things. Here's another example:
prod = z * w;
would be equivalent to
prod.Re = z.Re * w.Re;
prod.Im = z.Im * w.Im;
which is NOT the representation of the product of the complex numbers
represented by `z' and `w'. So what? YOUR fault, not the language's.
To Henry's remark
"You want C++, not C."
I say
"For the `struct complex' example? Maybe. But does this mean
any innovation should be swept off the table?"
As Bernard A. Badger Jr. says, "you throw out the useful comparisons with
the ill-defined ones. It is perfectly well-defined and quite handy
to define a simple member-by-member comparison on structs and arrays.
The only thing you give up are the unions. Comparison of pointers is
defined to be comparison of the pointers themselves, just as always."
Roelof Vuurboom again:
"I've still got an awful lot of structs *which occur in the real world*
for which I can (and several times wished I could) do a sensible comparison."
--
"Mom! Eric Newton broke the day! In 24 |Maarten Litmaath @ VU Amsterdam:
parts!" (Mike Schmitt in misc.misc) |maart@cs.vu.nl, mcvax!botter!maart
guy@auspex.auspex.com (Guy Harris) (07/23/89)
>Henry Spencer wrote something like > > "Then how about struct addition, sonny?" > >to which I say > > "Yes! Another useful struct operation!" Fine. Now what about complex *multiplication*? Doesn't sound like any generally-useful structure multiplication operation would do the trick. And what about division? Sorry, but if you want complex numbers as a data type in C that uses C operators, you can't get that just by pasting on new general "struct" operators; you either have to add it to the language, or go the C++ route. >Another point raised by Henry > > "How about polar representation of complex numbers and > non-uniqueness?" > >was nicely dealt with by Roelof Vuurboom. Mathematical problems caused by >(inadequate) representation of mathematical quantities, and language >definitions are two different things. Here's another example: > > prod = z * w; > >would be equivalent to > > prod.Re = z.Re * w.Re; > prod.Im = z.Im * w.Im; > >which is NOT the representation of the product of the complex numbers >represented by `z' and `w'. So what? YOUR fault, not the language's. Yes, but as far as I can tell the *ONLY* benefit of structure comparison as a "native" C operation is that it applies a bit of syntactic sugar frosting to the operation. Said frosting appears to have spoiled, in both the cases of polar representation and in the case of complex multiplication - so it appears that the "struct complex" example doesn't cut it as an argument for adding new structure operators. >To Henry's remark > > "You want C++, not C." >I say > "For the `struct complex' example? Maybe. But does this mean > any innovation should be swept off the table?" > >As Bernard A. Badger Jr. says, "you throw out the useful comparisons with >the ill-defined ones. It is perfectly well-defined and quite handy >to define a simple member-by-member comparison on structs and arrays. >The only thing you give up are the unions. Comparison of pointers is >defined to be comparison of the pointers themselves, just as always." > >Roelof Vuurboom again: >"I've still got an awful lot of structs *which occur in the real world* >for which I can (and several times wished I could) do a sensible comparison." OK, let's *see* the examples. I've only had any need for something looking like structure comparison once or twice, and the inconvenience of not having it was trivial. Somebody earlier said Ada had structure comparsion; OK, how often is it *really* used? Not all features of a given language are *ipso facto* useful. And as for "does this mean any innovation should be swept off the table", well, in a sense, yes. Innovation should be kept to a minimum in language standards; some amount of successful "prior art" - or unsuccessful "prior art" - should weigh a *lot* more in the decision to put something into a standard than should theoretical arguments for or against some feature. If you want structure comparison, put it into *your* compiler (or GCC, or whatever), and report back on its success or failure. Just because some feature seems nice does NOT mean it belongs in the current C standard.
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/23/89)
In article <2272@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > Sorry, but if you want complex numbers as a data type in C that uses C > operators, you can't get that just by pasting on new general "struct" > operators; you either have to add it to the language, or go the C++ > route. That's also my general observation: When I need composite objects, I practically always find that I also need operations on them beyond any simple model that could reasonably be supported directly via language operators. Complex multiplication is just one of the simplest examples. Since I have to provide a set of explicitly programmed operations anyway, it is not a lot of additional bother that the language doesn't directly support a few of them.
peter@ficc.uu.net (Peter da Silva) (07/24/89)
In article <10593@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > That's also my general observation: When I need composite objects, I > practically always find that I also need operations on them beyond any > simple model that could reasonably be supported directly via language > operators. Complex multiplication is just one of the simplest examples. This is a reasonable point, but do keep in mind that this is also true of simple objects. For example, when dealing with !(char *)! objects, don't you practically always find that you need operations on them beyond any simple model that could reasonably be supported directly via language operators? !strcmp()! is just one of the simplest examples. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "...helping make the world Personal: peter@sugar.hackercorp.com. `-_-' | a quote-free zone..." Quote: Have you hugged your wolf today? 'U` | -- hjm@cernvax.cern.ch