ANSI C questions (parameters, structure assignment)

[Richard A. O'Keefe]

In article <360 at saxony.pa.reuter.COM>, dgil at pa.reuter.COM (Dave Gillett) writes:
> In <3615 at goanna.cs.rmit.oz.au> ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >In article <352 at saxony.pa.reuter.COM>, dgil at pa.reuter.COM (Dave Gillett) writes:
> >: In <1081.26d26274 at desire.wright.edu> demon at 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 <op> CORRESPONDING <source> TO <destination> is to
walk over the symbol table, doing
	for each <field> in FieldsOf(<source type>) intersection
			    FieldsOf(<destination type>) do
	    compile the statement
		"<op> <field> OF <source> TO <field> OF <destination>"
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.