From: Ahem A Rivet's Shot on 2 Mar 2010 17:07 On Tue, 02 Mar 2010 13:24:00 -0500 Michael Wojcik <mwojcik(a)newsguy.com> wrote: > Ahem A Rivet's Shot wrote: > > On Fri, 26 Feb 2010 13:48:48 -0500 > > Michael Wojcik <mwojcik(a)newsguy.com> wrote: > > > >> Ahem A Rivet's Shot wrote: > >>> No, he's saying that C doesn't really implement an array type, > >>> the var[offset] syntax is just syntactic sugar for *(var + offset) > >>> which is why things like 3[x] work the same as x[3] in C. > >> That's not quite correct. C does implement an array type (or, rather, > >> an array type qualifier which can be used to implement arrays of any > >> object type); it's just not first-class. > > > > This is saying the same thing as I did in different terms and > > with greater detail. > > I supposed, if you want to gloss "doesn't really implement an array > type" as "does implement an array type". That seems rather a stretch > to me. That "first-class" bit is the "really". -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
From: Charles Richmond on 2 Mar 2010 17:38 Joe Pfeiffer wrote: > "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes: > >> On 24/02/2010 23:55, in article >> 1bmxyy42ag.fsf(a)snowball.wb.pfeifferfamily.net, "Joe Pfeiffer" >> <pfeiffer(a)cs.nmsu.edu> wrote: >> >>> When I was an undergrad I spent some time programming FORTRAN on a >>> Harris /6 (I think it was a /6 -- there's something nagging at the back >>> of my mind that says it may have been a /7). Anyway, reading the manual >>> I discovered that return addresses were stacked, and immediately jumped to >>> the conclusion that it could do recursion. It turned out that local >>> variables were static... which meant I spent a *long* time figuring out >>> why my program was producing completely nonsensical results. >>> >>> As Al Stewart once sang, "I was jumping to conclusions, and one of them >>> jumped back." >> People who assumed that FORTRAN local variables *must* be static got jumped >> on from the opposite direction when they used FORTRAN compilers that >> actually did put them on the stack, as the ANS FORTRAN standard was >> carefully worded to permit. > > All these decades I thought that was the case.... of course, I only > programmed FORTRAN for a couple of years around 1980. With the older FORTRAN's, you have to "know your implementation". Tricks were used especially to handle ASCII data in numeric variables in the early days. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: Peter Flass on 2 Mar 2010 20:02 Michael Wojcik wrote: > Peter Flass wrote: >> Hey! C's finally caught up to PL/I. Only took them 50 years, and then >> of course all the features are just tacked-on in true C fashion, instead >> of thought-through. > > Well, that's rather insulting to the members of WG14, who spent a > decade designing those features. Fortunately, they published the > Rationale showing that, in fact, they were thought through.[1] And a > great deal of documentation describing the process is available in the > archives.[2] > > If you'd care to show why you think otherwise, perhaps there would be > some grounds for debate. "The flexible array must be last"? "sizeof applied to the structure ignores the array but counts any padding before it"? C is a collection of ad-hoc ideas. WG14 may have put a great deal of thought into how to extend it without breaking the existing mosh, but that's my point, it's still a mosh.
From: bbreynolds on 3 Mar 2010 10:00 On Mar 2, 5:38 pm, Charles Richmond <friz...(a)tx.rr.com> wrote: > Joe Pfeiffer wrote: > > "(see below)" <yaldni...(a)blueyonder.co.uk> writes: > > >> On 24/02/2010 23:55, in article > >> 1bmxyy42ag....(a)snowball.wb.pfeifferfamily.net, "Joe Pfeiffer" > >> <pfeif...(a)cs.nmsu.edu> wrote: > > >>> When I was an undergrad I spent some time programming FORTRAN on a > >>> Harris /6 (I think it was a /6 -- there's something nagging at the back > >>> of my mind that says it may have been a /7). Anyway, reading the manual > >>> I discovered that return addresses were stacked, and immediately jumped to > >>> the conclusion that it could do recursion. It turned out that local > >>> variables were static... which meant I spent a *long* time figuring out > >>> why my program was producing completely nonsensical results. > > >>> As Al Stewart once sang, "I was jumping to conclusions, and one of them > >>> jumped back." > >> People who assumed that FORTRAN local variables *must* be static got jumped > >> on from the opposite direction when they used FORTRAN compilers that > >> actually did put them on the stack, as the ANS FORTRAN standard was > >> carefully worded to permit. > > > All these decades I thought that was the case.... of course, I only > > programmed FORTRAN for a couple of years around 1980. > > With the older FORTRAN's, you have to "know your implementation". > Tricks were used especially to handle ASCII data in numeric > variables in the early days. > In really older FORTRANs, you would more likely know the tricks used to handle BCDIC or SIXBIT character data as numeric variables. Bruce B. Reynolds, Trailing Edge Technologies, Warminster PA
From: Greg Menke on 3 Mar 2010 19:06
Peter Flass <Peter_Flass(a)Yahoo.com> writes: > Michael Wojcik wrote: >> Peter Flass wrote: >>> Hey! C's finally caught up to PL/I. Only took them 50 years, and then >>> of course all the features are just tacked-on in true C fashion, instead >>> of thought-through. >> >> Well, that's rather insulting to the members of WG14, who spent a >> decade designing those features. Fortunately, they published the >> Rationale showing that, in fact, they were thought through.[1] And a >> great deal of documentation describing the process is available in the >> archives.[2] >> >> If you'd care to show why you think otherwise, perhaps there would be >> some grounds for debate. > > "The flexible array must be last"? > > "sizeof applied to the structure ignores the array but counts any > padding before it"? > > C is a collection of ad-hoc ideas. WG14 may have put a great deal of > thought into how to extend it without breaking the existing mosh, but > that's my point, it's still a mosh. iostream formatting operators, because we really need more operator overloading and no enhancements are too bizarre in service of making everything, (for particular values of everything), specialized? Oh but wait, you can compile, install and dig your way through Boost so as to avoid the fun & games of vanilla iostream. Thank goodness printf and friends are still around. Which I suppose isn't an argument that the feature wasn't designed, but is perhaps in support of the "ad-hoc" argument. One more wacky idea thrown on the pile for the amusement of the programmer. Gregm |