ANSI C questions (parameters, structure assignment)

[Richard A. O'Keefe]

In article <365 at saxony.pa.reuter.COM>, dgil at 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.