glen herrmannsfeldt wrote:
> 
>     [snip...]             [snip...]            [snip...]
>  
>> As Al Stewart once sang, "I was jumping to conclusions, and one of them
>> jumped back."
> 

"If you stare into the Abyss long enough,
  the Abyss stares back at you."

     -- Friedrich Nietzsche

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

glen herrmannsfeldt wrote:
> In comp.arch.fpga Scott Lurndal <s...@slp53.sl.home> wrote:
> (snip, someone wrote)
>>>> Q?  Why would anyone want to pass an array by value?
> 
>>> Why would anyone want to wrap an array in a struct and pass that by value?
>  
>> Why answer a question with another question?
>  
>> 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.
> 
> It might make sense for a small array.  You might have an rgb
> array dimensioned [3] instead of three separae variables.  
> The dimension, I believe, has to be a compile time constant.
> 
> -- glen 

Heck, for RGB, just use a struct with three variables in it.

The dimensions of arrays *used* to have to be compile time 
constants. Now they have a type of array declared in a function 
that can have its size depend on an integer passed into the 
function. (I forget what they call it...  maybe a "dynamic array" 
or something.)

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

Joe Pfeiffer wrote:
> glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> 
>> In comp.arch.fpga Scott Lurndal <s...@slp53.sl.home> wrote:
>> (snip, someone wrote)
>>>>> Q?  Why would anyone want to pass an array by value?
>>>> Why would anyone want to wrap an array in a struct and pass that by
value?
>>  
>>> Why answer a question with another question?
>>  
>>> 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.
>> It might make sense for a small array.  You might have an rgb
>> array dimensioned [3] instead of three separae variables.  
>> The dimension, I believe, has to be a compile time constant.
> 
> It doesn't.  You can use malloc() to allocate an arbitrary-sized buffer,
> and then use array syntax to access elements of the buffer.  You can
> also pass the address of the buffer, and use it like an array in the
> called procedure.
> 
> 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];

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

In comp.arch.fpga Charles Richmond
<f...@tx.rr.com> wrote:
(snip)
 
> Heck, for RGB, just use a struct with three variables in it.

Well, the suggestion was an array in a struct.  With an array
you can loop over it.
 
> The dimensions of arrays *used* to have to be compile time 
> constants. Now they have a type of array declared in a function 
> that can have its size depend on an integer passed into the 
> function. (I forget what they call it...  maybe a "dynamic array" 
> or something.)

Yes, but can you do that for an array in a struct.  If you 
pass it in a function call, and it isn't the last argument, how
will the called routine know where the other arguments are?

I haven't done much with C99 yet.

-- glen
 

On Wed, 24 Feb 2010 11:31:45 -0800 (PST)
Eric Chomko <p...@comcast.net> wrote:

> On Feb 23, 2:07 pm, "(see below)" <yaldni...@blueyonder.co.uk>
wrote:
> > On 23/02/2010 17:52, in article
> > 3ec03225-3a0f-4bcd-9db1-51201d1b3...@w12g2000vbj.googlegroups.com, "Eric
> >
> > Chomko" <pne.cho...@comcast.net> wrote:
> > > But an ALGOL "activation record" (stack frame) had a lot more
than
> > > that. As I recall, they copied a lot more just pointers and parameter
> > > values.
> >
> > Just the usual red tape: return address, frame pointer of caller; and
> > either a static pointer or some housekeeping for 'display' registers
> > (if used) 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, unlike C.
> >
> 
> Are you saying that C doesn't implement true recursion? I have only

	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.

-- 
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/

Charles Richmond wrote:
> A "thunk" was *and* is a method for implementing "call by name".
But a
> compiler providing "thunks" has *not* been written for some time now.

That's rather dubious.

We don't know that no one has written a compiler that provides
ALGOL-style thunks recently. To demonstrate that you'd have to prove a
negative.

If we relax the definition to allow named as well as anonymous
functions, then someone could argue that get-accessors for properties
are thunks, and those are quite common in modern languages.

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

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.

Array access syntax is syntactic sugar for multiply-add-dereference,
but arrays aren't just syntactic sugar, because array definitions
reserve storage and permit initialization. Also, array and pointer
lvalues are interpreted differently, even in contexts where they
former decays to the latter, which is why an external array
declaration is not equivalent to an external declaration of a pointer
to the same object type.[1]

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.


[1] Probably the best treatment of this question is in PvdL's _Expert
C Programming_, chapter 4, "The Shocking Truth: C Arrays and Pointers
Are NOT the Same!", and chapter 9, "More About Arrays".

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

(see below) wrote:
> On 24/02/2010 20:37, in article h...@news6.newsguy.com, "Michael
> Wojcik" <m...@newsguy.com> wrote:
> 
>> (see below) wrote:
>>> But bear in mind that in decent languages arrays are
>>> storable values, so a value array parameter gets copied in toto, unlike C.
>> It will be in C if the array is wrapped in a struct. Letting array
> 
> That is passing a struct, not an array.

Yes, that's what I said. Of course, if the array is the only thing in
the struct, then the distinction is purely syntactic.

>> 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?

Other than the name of the keyword struct, no, it seems pretty
reasonable to me. Parameters should be primitives or ADTs.

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

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.

If the callee would have had to make a copy of the array anyway, why
not let the compiler do the work?

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

Joe Pfeiffer wrote:
> glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>> In comp.arch.fpga Scott Lurndal <s...@slp53.sl.home> 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.
>> It might make sense for a small array.  You might have an rgb
>> array dimensioned [3] instead of three separae variables.  
>> The dimension, I believe, has to be a compile time constant.
> 
> It doesn't.  You can use malloc() to allocate an arbitrary-sized buffer,
> and then use array syntax to access elements of the buffer.  You can
> also pass the address of the buffer, and use it like an array in the
> called procedure.

That doesn't work for a pass-by-value array, which is what we're
talking about here. You can only pass an array by value in C if it's
an array type that's a member of a struct (or union, which is just a
special case of struct).

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