Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: ANSI C questions (parameters, structure assignment) Message-ID: <3636@goanna.cs.rmit.oz.au> Date: 29 Aug 90 09:09:30 GMT References: <1081.26d26274@desire.wright.edu> <352@saxony.pa.reuter.COM> <360@saxony.pa.reuter.COM> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 78 In article <360@saxony.pa.reuter.COM>, dgil@pa.reuter.COM (Dave Gillett) writes: > In <3615@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > >In article <352@saxony.pa.reuter.COM>, dgil@pa.reuter.COM (Dave Gillett) writes: > >: In <1081.26d26274@desire.wright.edu> demon@desire.wright.edu writes: > >: >struct_thing -= still_more_struct; > >: >struct_thing *= even_more_struct; [and I pointed out that COBOL has the equivalent of it] > First of all, it's not obvious to me that this is the semantics that "demon" > had in mind. He later said that it was. > But secondly, we have the assertion that "there is nothing in the language > which would make it especially difficult to implement", and I'm not sure > that's true at all. There is nothing in C to make it harder than COBOL. Pointers could cause problems, but addition (subtraction) of pointers is not defined (does not yield a pointer) so would continue to be illegal. > I can envision a number of scenarios where it would > have to be extremely awkward, some cases where a diagnostic message should > be issued but it could be extremely diifficult to pinpoint the error being > diagnosed, and at least one killer case: where two names appear in a union > in the destination struct but as separate components of the source struct. > The result should store two different values into a single location. This is not a killer case at all. It's a solved problem. The very same situation can occur in COBOL (look up "level 66 items"). Do bear in mind that I was *NOT* recommending it as an extension to C, merely observing (a) that it wasn't completely loony and (b) that the same methods COBOL compilers use for the job could be adapted if anyone wanted to hack their copy of GCC or of Holub's code or whatever. > C is a structured language. COBOL is not. Where have you been? Every control structure that C has, COBOL has. The current version of COBOL even has nested "programs", something that C lacks. (Yes, I *do* mean that a single COBOL text is no longer restricted to one global pool of variables. And yes, modern COBOL control structures are not tied to labelled paragraphs.) > The distinction is *not* moot. Perhaps you might like to explain in comp.lang.misc precisely what it is that makes C (according to the current standard) "structured" but COBOL (according to the current standard) "not structured". > "CORRESPONDING" is a powerful feature, and its implementation cost is, I'm > sure. much higher than you think--and places non-trivial demands on the > data declaration portions of the language. Corresponding has no *RUN-TIME* consquences whatsoever. Basically all that is required to implement CORRESPONDING TO is to walk over the symbol table, doing for each in FieldsOf() intersection FieldsOf() do compile the statement " OF TO OF " I oversimplify, but it is is a *well* understood problem, and there would be no impact on the data declaration portion of the language whatsoever. > I'm pretty certain that trying to add this feature to C would be a > monumental mistake. That's a completely different question. I repeat, my point was that the original poster seemed to be talking about something which was present in at least one other langauge, whose implementation is well understood, and for which the *only* change to the C language would be to render more expressions defined. Whether it would be a good idea to *do* it is quite a different question. I don't think it would be myself, and I always shunned CORRESPONDING when I used COBOL (on program maintenance grounds; to someone reading the program it was never clear just what was going on). -- You can lie with statistics ... but not to a statistician.