On Feb 26, 5:54=A0pm, Peter Flass
<Peter_Fl...@Yahoo.com> wrote:
> Scott Lurndal wrote:
> > "(see below)" <yaldni...@blueyonder.co.uk> writes:
> >> On 24/02/2010 20:37, in article hm6fbd6...@news6.newsguy.com, "Michael
> >> Wojcik" <mwoj...@newsguy.com> wrote:
>
> >>> (see below) wrote:
> >>>> Just the usual red tape: return address, frame pointer of caller;
an=
d either
> >>>> a static pointer or some housekeeping for 'display' registers (if
us=
ed) to
> >>>> access non-locals. But bear in mind that in decent languages arrays
=
are
> >>>> storable values, so a value array parameter gets copied in toto,
unl=
ike C.
> >>> It will be in C if the array is wrapped in a struct. Letting array
> >> That is passing a struct, not an array.
>
> >>> parameters decay to pointers was a feature of early C that couldn't b=
e
> >>> changed for historical reasons, but when the standardization committe=
e
> >>> added support for struct parameters, they made them first-class.
> >>> struct (and not the misnamed "typedef") is C's mechanism for
creating
> >>> new types and ADTs, so if you want a pass-by-value array in C, the
> >>> correct thing to do is to put it in a struct.
> >> Yes. Preposterous, isn't it?
>
> > Q? =A0Why would anyone want to pass an array by value?
>
> Because you can?

In Perl there is the 'shift' statement, which allows access to an
array by value.

Michael Wojcik <m...@newsguy.com>
writes:
>Scott Lurndal wrote:
>> 
>> I've never promoted or suggested that one put an array in a struct
>> and pass it by value, I frankly think it would be a stupid thing to
>> do in a C program.
>
>Is it a stupid idea, or a good one, in all the languages that support
>it? Is this just a special attribute of C?

Perhaps stupid was a bit strong.  As an OS designer/implementer, I
find the copy to be a problem;  perhaps for other applications, it
would make some sense (although most the apps I can think of that
process arrays are probably better off in FORTRAN or R or Mathematica.

>
>> I was curious if anyone thought passing an array by value was a
>> _good_ idea.
>
>It might be if you want the callee to be able to modify its copy of
>the array without affecting the caller's. Just like any other
>pass-by-value object.
>
>If the callee would have had to make a copy of the array anyway, why
>not let the compiler do the work?

Yes, a point.  However, I'd be concerned about the adverse affect on
performance if used for subtantially large arrays.

scott

Charles Richmond <f...@tx.rr.com>
writes:
> Joe Pfeiffer wrote:
>>
>> Since C99, you can allocate an array with a variable number of elements
>> like this:
>>
>>     printf(" array size >> ");
>>     scanf("%d", &size);
>>
>>     int awry[size];
>
> But how about the second dimension, Joe??? Can you allocate:
>
>       int awry2[size][size];

Yes (just tried it)
-- 
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

Joe Pfeiffer wrote:
> Charles Richmond <f...@tx.rr.com> writes:
>> Joe Pfeiffer wrote:
>>> Since C99, you can allocate an array with a variable number of elements
>>> like this:
>>>
>>>     printf(" array size >> ");
>>>     scanf("%d", &size);
>>>
>>>     int awry[size];
>> But how about the second dimension, Joe??? Can you allocate:
>>
>>       int awry2[size][size];
> 
> Yes (just tried it)

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.

"(see below)"
<y...@blueyonder.co.uk> writes:

> On 24/02/2010 23:55, in article
> 1...@snowball.wb.pfeifferfamily.net, "Joe Pfeiffer"
> <p...@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.
-- 
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

glen herrmannsfeldt wrote:
> In comp.arch.fpga Michael Wojcik <m...@newsguy.com> wrote:
> (snip on C, arrays, and such)
>  
>> Array types aren't first-class because when used as formal parameters
>> they're converted to pointer types, and when used as actual parameters
>> they decay to a pointer to their first element. This is similar to C's
>> other second-class type, the function type, which decays to a function
>> pointer in every context except declaration and definition.
> 
> How do you classify Fortran arrays.  (Specifically "assumed  size"
> arrays in newer Fortran versions, the only ones they had in older
> versions.)

It's been too long since I used Fortran (or FORTRAN, of whatever
vintage) in anger to speculate on the subject. The main thing I
remember about Fortran arrays is that they're in column-major order,
so when I worked on Fortran bindings for graphics libraries written in
C, I had to transpose the arrays. (This was when I worked on the X11
implementations of GKS and PEX at IBM.)

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Ahem A Rivet's Shot wrote:
> On Fri, 26 Feb 2010 13:48:48 -0500
> Michael Wojcik <m...@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.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Charles Richmond wrote:
> Michael Wojcik wrote:
>>
>> (Technically, C says nothing about a stack. A conforming C
>> implementation could use activation frames that contain XML documents
>> describing each parameter in detail. It could use an indexed file to
>> implement the call stack. It could implement calls by generating
>> subprograms on the fly that get their parameters via pipes. If they
>> get there on the backs of unicorns ridden by nasal demons, that's OK
>> with the standard too.)
> 
> Sure the implementation is left up to the compiler writer. But however
> the arguments are passed and the functions called, the implementation is
> *equivalent* to using a stack... because it accomplishes the same thing.

Yes, yes, obviously. I must remember henceforth to add a standard
disclaimer to any similar posts.

The point still stands: C says nothing about a stack, and that
includes nothing about a contiguous stack with no metadata. An
implementation is free to provide a stack-equivalent that describes
the activation in glorious detail, and so accommodates all sorts of
things that are difficult to implement with a dumb stack.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Joe Pfeiffer wrote:
> Michael Wojcik <m...@newsguy.com> writes:
> 
>> Scott Lurndal wrote:
>>> I've never promoted or suggested that one put an array in a struct
>>> and pass it by value, I frankly think it would be a stupid thing to
>>> do in a C program.
>> Is it a stupid idea, or a good one, in all the languages that support
>> it? Is this just a special attribute of C?
>>
>>> I was curious if anyone thought passing an array by value was a
>>> _good_ idea.
>> It might be if you want the callee to be able to modify its copy of
>> the array without affecting the caller's. Just like any other
>> pass-by-value object.
> 
> I think the point is that this is unlikely to be a good thing to do to
> an array.  I'm not terribly sure it's often a good idea for anything
> else, either!

It's the moral equivalent of the OO idiom where a temporary object is
created from a parameter via copy constructor, then discarded and
eventually reclaimed by garbage collection. IME, that's quite common
in a lot of OO applications (in OO languages with garbage collection,
of course).

Whether it's a Good Thing is highly contextual and largely subjective,
of course.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Scott Lurndal wrote:
> Michael Wojcik <m...@newsguy.com> writes:
>> Scott Lurndal wrote:
>>> I've never promoted or suggested that one put an array in a struct
>>> and pass it by value, I frankly think it would be a stupid thing to
>>> do in a C program.
>> Is it a stupid idea, or a good one, in all the languages that support
>> it? Is this just a special attribute of C?
> 
> Perhaps stupid was a bit strong.  As an OS designer/implementer, I
> find the copy to be a problem;  perhaps for other applications, it
> would make some sense (although most the apps I can think of that
> process arrays are probably better off in FORTRAN or R or Mathematica.

I'll agree that when I write C code (which until recently was most of
the time; these days I happen to be writing mostly OO COBOL,
ECMAScript, and occasionally PHP and Ruby), I like to keep a close
watch on memory consumption - partly because I'm likely writing system
code that needs to be conservative, and partly because C encourages
that mindset.

This is particularly true with automatic allocation and multithreaded
programs. I've had to correct far too many thread-stack-overflow bugs
(pretty much always in someone else's code) because of auto-class
variable abuse.

>>> I was curious if anyone thought passing an array by value was a
>>> _good_ idea.
>> It might be if you want the callee to be able to modify its copy of
>> the array without affecting the caller's. Just like any other
>> pass-by-value object.
>>
>> If the callee would have had to make a copy of the array anyway, why
>> not let the compiler do the work?
> 
> Yes, a point.  However, I'd be concerned about the adverse affect on
> performance if used for subtantially large arrays.

Yes. You'd want to restrict this to quite small objects, I think.

In general, explicit allocation of copies from the heap is the better
idea in C programs, because it gives you much better error handling.
There's no standard mechanism for dealing with hitting the stack
limit, and even the extensions offered by various implementations
don't help much.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University