Mark Wooding wrote:
> ru...@yahoo.com <ru...@yahoo.com> wrote:
>> Mark Wooding wrote:
>> > ru...@yahoo.com <ru...@yahoo.com> wrote:
>...
>> > For another:
>> >
>> > static void bar(char v[]) { char ch = 0; v = &ch; }
>> > /* type error if arrays truly passed by reference */
>>
>> v can be used as an array reference, e.g. "v[1] = 23"
>> exactly as in the pass-by-reference fortran example. And
>> v can also be used as a local variable and reassigned.
>
>> If the first option was the only one, would you not
>> say C was definitely pass-by-reference (for arrays)?
>> If one could only use v as a pointer (i.e. access
>> the argument array as "*(v+1) = 23", then I would
>> say that arrays are not passed at all, only pointers
>> by-value.
>
> Your knowledge of C is clearly limited, at best. The notations *(p + i)
> and p[i] are entirely equivalent in every way, since the square-brackets
> indexing operator is in fact defined in terms of pointer dereference
> (6.5.2.1):
>...
Yes, my C experience is limited. I very rarely write
any C these days and even many years ago when I wrote
more, it was very vanilla stuff not requiring any deep
knowlage of dark corners of the language.
Nevertheless, I am aware of everything you wrote above
(the gist, not the standard's verbiage) and the common
demonstration of it: 3["surprised?"] => 'p'.
But if you'll note, I said "if ..." referring to a couple
of hypothetical C-like languages, so your chapter-and-verse
quote from the standard, while interesting and appreciated,
was basically irrelevant.
>...
>> > Also, notice that arrays in expressions turn into pointers in the same
>> > way, so function argument passing works the same way as assignment -- a
>> > hallmark of pass-by-value.
>>
>> Not in all expressions as you yourself mentioned:
>> int a[10], *ap;
>> sizeof a;
>> sizeof ap;
>
> Well done, you've pedantically picked up on the lapse in the first part
It isn't pedantic. It is the only thing (IFAIK) that
allows one to talk about variables of an array type (as
opposed to only pointers).
>...
> Since I'm getting thoroughly fed up of repeating myself on this point,
> I'm simply going to assume, from now on, that anyone who offers a
> disagreement without citing passages from (at least a specific draft of)
> ISO 9899 to support any claims made is simply being wilfully ignorant --
> and therefore no longer worth my attention.
>
> (If you don't have a copy of any such version, may I suggest
>
> http://std.dkuug.dk/jtc1/sc22/open/n2794/
>
> citing this (confusingly) as n843, as a place to start.)
Actually I've already downloaded a C89/90 standard draft
in the hope that an earlier version would be simpler.
Since C's behavior vis "call-by-x" is (I presume) unchanged
back to K&R, whatever it said about it should be confirmable
by any ealier versions descriptions of C.
But more importantly, we seem to be talking at cross
purposes.
My idea of a language model is a description of the
language that is precise enough to allow a model's
user to predict how any piece of code will behave when
run.
The C-standard(s) do that for C. Since many people
would claim that a language that does not behave as
the C standard describes is not C, it is definitional,
and one cannot reasonably say that the model presented
in the C standard is incorrect. (Of course, like all
standards, the C standard is not perfect, it contains
errors and inconsistencies that require correction,
and like all languages, C evolves requiring new versions
of the standard.)
Nevertheless, I see no reason to believe, based on
anything said in this thread, or my experience in
general, that there can be *only* one correct model
of a language, or part of a language.
So all the quoting of the C standard in the world
does not address the issue: can C's array passing be
described (modeled) as pass-by-reference?
I acknowledge that the C standard provides one
(correct) model in which arrays aren't passed, only
pointers by-value.
To address the issue you need to show that an alternate
model (array passing by-reference for example) is incorrect,
i.e. leads it user to conclude that a program will behave
differently than it does. And of course, when such a
discrepancy model and behavior is pointed out, the proposer
of the alternate model will fix it if possible.
If you can not show that an alternate model is incorrect,
then the next best thing is to show that your model is
better. Better would involve considerations such as simpler,
consistent with other languages, easier to understand by
various categories of users, etc. Obviously this is a
very subjective task, and one could expect disagreement.
Many of the responses by you, Joe, and others, have
an "of course this model is the right one, how could
anyone think otherwise" tone to them. I hope I have
explained clearly why I think that attitude is unjustified.
Finally, and please don't be insulted by this, but to
me and many readers, you are a bunch on glowing dots
on a screen. I have been using the internet long enough
to have any number of times read very plausible, authoritative
sounding tomes only to find out later they were BS, or
a least, not as widely accepted as gospel as the author
proclaimed.
All that not withstanding, thank you for taking the time
to respond in the depth you have. I appreciate it and
have clarified a lot of my thinking on the subject as
as result.
--
http://mail.python.org/mailman/listinfo/python-list
