Charles Richmond <f...@tx.rr.com>
writes:

> Yes, "2[c]" does work in C as well as "c[2]", and yields the
same
> results. The definition of "c[x]" is "*(c+x)", where the array
"c"
> becomes a pointer to the first element, and the integer value "x" is 
> scaled by the length associated with the pointer "c". "*(c+x)"
will 
> give the same result as "*(x+c)", so it's logical. 

Just curious, but why is it that "2[c]" doesn't seem to work as an
argument to printf? This simple example gives an error at compile, for
example:

#include <stdio.h>

int main()
{
  char c[] = "12345678";
  printf("%c\n", [2]c);
}

gcc says:

array_fun_mini_example.c: In function 'main':
array_fun_mini_example.c:6: error: expected expression before '[' token

I'm using gcc 4.3.2. Assignment like 2[c] = '1' and reading a value
like tmp = 2[c] seem to work fine, though.

Anssi Saari <a...@sci.fi> writes:

> Charles Richmond <f...@tx.rr.com> writes:
>
>> Yes, "2[c]" does work in C as well as "c[2]", and yields the
same
>> results. The definition of "c[x]" is "*(c+x)", where the
array "c"
>> becomes a pointer to the first element, and the integer value "x" is 
>> scaled by the length associated with the pointer "c".
"*(c+x)" will 
>> give the same result as "*(x+c)", so it's logical. 
>
> Just curious, but why is it that "2[c]" doesn't seem to work as an
> argument to printf? This simple example gives an error at compile, for
> example:
>
> #include <stdio.h>
>
> int main()
> {
>   char c[] = "12345678";
>   printf("%c\n", [2]c);
> }
>
> gcc says:
>
> array_fun_mini_example.c: In function 'main':
> array_fun_mini_example.c:6: error: expected expression before '[' token
>
> I'm using gcc 4.3.2. Assignment like 2[c] = '1' and reading a value
> like tmp = 2[c] seem to work fine, though.

Possibly because your program uses [2]c, not 2[c].
-- 
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)

Brian Boutel wrote:
> Michael Wojcik wrote:
>>
>> 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.
> 
> In functional languages with lazy evaluation (e.g. Haskell) arguments
> are passed unevaluated, so an actual argument that is an expression
> needs to be parcelled up as a piece of code and an environment in which
> is is to be evaluated (i.e the bindings of the free variables in the
> code). This amounts to a thunk.

Good point. I have a passing familiarity with lazy evaluation, but
even with functional programming most of my experience is with
eager-evaluating languages like OCaml, so I didn't think of this example.

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

Ahem A Rivet's Shot wrote:
> 
> 	No but x = *(y + 3) will store in x the contents of the memory
> location at 3

... times the size in bytes[1] of the base type of y, which must be an
object pointer type ...

> + the value of y just as x = y[3] will and x = 3[y] will,
> which is what I stated.


[1] "bytes" as defined by the C Standard, ie the size of a char
object, which may or may not be an octet.

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

Quadibloc wrote:
> 
> Yes: the array name always refers to the pointer,

No, not "always", as has been pointed out more than once in this thread.

There are specific contexts where an identifier of array type decays
to a pointer to its first element. There are others where it does not,
such as when it is the operand of the sizeof operator.

This is all spelled out quite clearly in the C standard, and in
various other references, some of which were cited upthread.

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

Peter Flass wrote:
> 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"?

Doing otherwise would break existing code. WG14's remit is to maintain
upward compatibility.

> "sizeof applied to the structure ignores the array but counts any
> padding before it"?

I have no idea what you're quoting there. That phrase doesn't seem to
be present in my copy of the standard.

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

If that was your point, then I have to say it was rather ill-expressed.

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

Greg Menke wrote:
> 
> C++ does make for a nice "type-safe linking" C compiler.

Except that it's not a C implementation, and so is not a C compiler at
all.

C and C++ are different languages.

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

Greg Menke wrote:
> Peter Flass <P...@Yahoo.com> writes:
> 
>> 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?

How fortunate, then, that C does not have them.

> Oh but wait, you can compile, install and dig your way through Boost so
> as to avoid the fun & games of vanilla iostream.

Not in C, you can't.

> Thank goodness printf and friends are still around.

Indeed, since a great number of C programs use them, and the committee
is explicitly charged with maintaining upward compatibility from the
first standard.

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

Michael Wojcik <m...@newsguy.com>
writes:


> Greg Menke wrote:
>> 
>> C++ does make for a nice "type-safe linking" C compiler.
>
> Except that it's not a C implementation, and so is not a C compiler at
> all.
>
> C and C++ are different languages.

Perhaps so, yet it is possible to compile C programs with a C++ and
observe some benefits relating to better compile-time and link-time type
checking.  One can then disassemble the object modules created by C vs
C++ compilers and observe the distinct similarity of with respect to the
runtime structure.

Which is why it "makes for a nice C compiler", not "is a better C
compiler".

Gregm

Michael Wojcik <m...@newsguy.com>
writes:

> Greg Menke wrote:
>> Peter Flass <P...@Yahoo.com> writes:
>> 
>>> 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?
>
> How fortunate, then, that C does not have them.

You are quoting out of context.  

The original topic to which I followed up via the above quote was
related to the sometimes "undesigned" appearance of C++.  The particular
quote above suggests C was already a collection of ad-hoc ideas, so that
C++ is not a substantial departure from existing practice.


>> Oh but wait, you can compile, install and dig your way through Boost so
>> as to avoid the fun & games of vanilla iostream.
>
> Not in C, you can't.

See above.

>
>> Thank goodness printf and friends are still around.
>
> Indeed, since a great number of C programs use them, and the committee
> is explicitly charged with maintaining upward compatibility from the
> first standard.

See above.

Gregm