From: Ahem A Rivet's Shot on
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
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
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
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

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