From: Michael Wojcik on 26 Feb 2010 13:29 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
From: Michael Wojcik on 26 Feb 2010 13:51 (see below) wrote: > On 24/02/2010 20:37, in article hm6fbd68gp(a)news6.newsguy.com, "Michael > Wojcik" <mwojcik(a)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
From: Michael Wojcik on 26 Feb 2010 14:02 glen herrmannsfeldt wrote: > In comp.arch.fpga Charles Richmond <frizzle(a)tx.rr.com> wrote: > (snip) > >> 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. No. The size of a struct type must be known at compile time, even in C99. > 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? If you *could* do this, that'd be an implementation issue, and outside the scope of the C language. :-) (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.) -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 26 Feb 2010 13:48 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
From: Michael Wojcik on 26 Feb 2010 13:55
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 |