Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!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: <3663@goanna.cs.rmit.oz.au> Date: 3 Sep 90 01:51:22 GMT References: <1081.26d26274@desire.wright.edu> <352@saxony.pa.reuter.COM> <365@saxony.pa.reuter.COM> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 83 In article <365@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 original poster made it clear that *when applied to his specific problem* adding or subtracting corresponding fields was what he intended *in that specific case*. He didn't describe a general 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. Why doubt it? Why not go and find out? It's a solved problem because "corresponding" is defined so that it *can't* *happen*. The two fields simply do *not* "correspond". No parallelism is involved. > >> C is a structured language. COBOL is not. > >Where have you been? Every control structure that C has, COBOL has. > 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. As far as I have been able to find out, "X is a structured language" means "I like X". By my standards, C is an incredibly unstructured language. (ML is _my_ idea of a structured language, and I'm willing to concede that Ada is structured. But C? Pull the other one.) > 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. Surely the syntax of C is widely agreed to be its weakest feature? Speaking of nesting, how come a language that *doesn't* provide nested procedures (C) qualify as structured, while one that *does* (modern COBOL) fails? Surely the common understnading of what makes a language "structured" has something to do with semantics (what combinations can be expressed) rather than syntax (the specific notation used to express things)? Is saying, for example, X+Y rather than (plus X Y), so enormously significant? Are we C-lovers to remain helpless against the onslaughts of Herman Rubin who complains about having to use functional notation? > 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 specific things? Bear in mind that over the years COBOL _has_ dropped several things (such as the ALTER verb). > Oops, I just did that [described the "structured" distinction] in general > terms above. I expect that most of the people in comp.lang.misc already > understand the distinction. I'm sure I _shall_ understand the distinction as soon as you take the trouble to explain what it _is_. > 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)?), I _can_ say O(n^2), but why should I? It's an O(n) process. (Basically it is a set intersection.) > (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 agree completely. That's why I never used CORRESPONDING when I used to write COBOL. That's why I'm not advocating this as an extension of C, just pointing out that it wasn't completely loony. -- You can lie with statistics ... but not to a statistician.