Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!rex!ukma!seismo!uunet!saxony!dgil From: dgil@pa.reuter.COM (Dave Gillett) Newsgroups: comp.lang.c Subject: Re: ANSI C questions (parameters, structure assignment) Message-ID: <365@saxony.pa.reuter.COM> Date: 2 Sep 90 10:04:44 GMT References: <1081.26d26274@desire.wright.edu> <352@saxony.pa.reuter.COM> <360@saxony.pa.reuter.COM> <3636@goanna.cs.rmit.oz.au> Organization: Reuter:file Inc (A Reuter Company) Palo Alto, CA Lines: 144 In <3636@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >In article <360@saxony.pa.reuter.COM>, dgil@pa.reuter.COM (Dave Gillett) writes: >> 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. Oh, but he didn't. The semantics that he gave were *considerably* less ambitious than what you're suggesting. The result would be the same for trivial cases, but it's not hard to construct an example that does one thing under his semantics and another under yours. >> 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. That's true, "-=" and "+=" require that the result be stuffed back into one of the operands, and so should not work on pointers. No disagreement here. >> 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"). "A solved problem"? I seriously doubt it. It's quite possible that a convention has been agreed upon, but the fact is that you have parallel operations (pieces of an atomic operation) whose result depends on the order in which they are evaluated. AT VERY LEAST, YOU MUST GET A COMPILER WARNING ON THIS. Probably a compiler that allows this will produce results in a reliable and consistent manner, but if anybody has managed to get the agreement of a standards committee (or even of two programmers!) on this, I'd be very surprised. That it can occur in COBOL I have no doubt. That it is a "solved problem" in any sort of general sense, is harder to believe. >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. Do bear in mind that I was merely observing that it was (a) not well-enough defined to determine whether it was loony or not, and (b) that it was not well-enough defined to tell whether the methods that COBOL compilers use for the job, assuming it was defined to be the same job as COBOL compilers do, was an appropriate approach--and that adding these methods to C compilers was likely to be much more complex a job than you seemed to realize. >> 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.) And if you think that "structured language" simply means "supplies the control structures recommended for doing structured programming" then you clearly didn't understand the distinction I was making. The characteristics that I refer to are not extra features that can be grafted on--they have to do with how various language structures combine and nest, with the syntax of the language rather than its semantics. Being able to do, in modern COBOL, everything you can do in C, doesn't qualify. In order for COBOL to become a structured language, you'd have to stop being able to do things that were allowed in it 15 years ago, which means that you break an awful lot of existing code and probably can't call it COBOL any more. >> 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". Oops, I just did that in general terms above. I expect that most of the people in comp.lang.misc already understand the distinction. (I could be wrong about that....) >> "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. Okay, I phrased it badly. Currently, a compiler trying to resolve a name reference has a fairly easy time of it--take the explicit name from the source line, and match it in the symbol table to get (a) type information, and (b) location information, typically as an offset from some base to be determined at link/load time. The type information can be used to determine whether the operation specified by the source is correct or not. Now in the CORRESPONDING case, the compiler has to generate a whole bunch of implicit references from doing symbol table lookups, try to match each one of those with another symbol table lookup (can you say O(n^2)?), and determine from the type information whether the specified operation is to be done--with the added proviso that illegal operations are not errors, but are just to be ignored. (The idea of a compiler that "knows" that I didn't mean to specify an illegal operation, so it can safely ignore it, contradicts everything my experience with software engineering has taught me.) >> 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). Well, I don't consider the feature, or its implementation, well understood. (And since you failed to grasp the differences between CORRESPONDING and the semantics that "demon" turned out to actually have in mind, and also that "structuredness" is a syntactic feature of a language and not a collection of semantic features, I don't accept your assertion that it is well understood. Fair enough?) Dave