Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!nuchat!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.lang.c
Subject: Re: Question on structures
Message-ID: <1040@sugar.UUCP>
Date: Sun, 8-Nov-87 17:13:44 EST
Article-I.D.: sugar.1040
Posted: Sun Nov  8 17:13:44 1987
Date-Received: Tue, 10-Nov-87 05:23:47 EST
References: <1025@phoenix.Princeton.EDU> <2986@mit-vax.LCS.MIT.EDU> <3048@psuvax1.psu.edu>
Organization: Sugar Land UNIX - Houston, TX
Lines: 39

In article <3048@psuvax1.psu.edu>, schwartz@gondor.psu.edu (Scott E. Schwartz) writes:
> In article <5673@weitek.UUCP> rober@weitek.UUCP (Don Rober) writes:
> >>A simple solution (sligthly inefficient). Rewrite
> >>	with a.b.c begin
> >>		d = 10 ;
> >>	end
> >>as
> >>	{
> >>	 struct <whatever> *s = &a.b.c ;
> >>	 s->d = 10 ;
> >>	}
> >A vastly superior solution in that there is nothing implicit happening.  The 
> >typical Pascal error is that it is never clear what 'd' is a reference to.
> 
> Typical for who?  Anyone framiliar with nested block structured languages
> should have no problem with this.  Certainly "never" is too strong a
> qualifier.

{$include structs.hdr}

procedure mung(e: integer);
var d: integer;
begin
    with a.b.c begin
	d = 10.5; d = d + e
    end
end;

Looking at this program, can you tell me what the compiler will do? Is d
an element of a.b.c, of type float, or isn't it? Is e part of d, or the
calling argument to mung. Now whenever you add an element to a record
you have to look at ALL the code that might use the record to look for
puns like this. In 'C' it's explicit.

Yes, Virginia, there are advantages to 'C' over Pascal. (and vice-versa,
naturally).
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.