Hi,

Irrwhan35 wrote:
<<
There is no "passing by reference" in C. Forget it. No
references. Only *values*. Everything is passed *by* *value* in C. You
will never pass "an array" to a function call in C. You will instead
pass the *value* of a *pointer* to a contiguous region of RAM which
contains the elements of your array. You pass *an adress*, namely the
address of the first position in RAM where your array stays, not "the
array", or a reference to the array. And this is implemented by
copying on the stack the *value* of the pointer (i.e., the address),
so that your function can access the array that start at that address.
>>

I think, we both are saying the same things, but using different words
that may have slightly different meanings for us. All code
instructions are finally translated into machine instructions which
involve reads from and writes to RAM and CPU registers. The CPU only
understands register indices/addresses/names and memory addresses and
a set of instructions which tell it which logic circuit to use to
process data. Therefore, a function's actual parameter declared by a
program language has to be translated into an address at some point
before execution. The choice of what to use for this address is two
way: a) either use the same address of the variable with the same name
in the same scope or copy the data without bothering about the
original address of the actual variable. When using the variable's
address it is equivalent to having a pointer and copying the data, is
just like having a local variable that is forgotten as soon as the
function exits. By "Passing by Reference" I always understood using
pointers behind the scenes by the programming language.

This is why I am finding it hard to logically accept that "passing by
reference" is NOT equivalent to passing a pointer for the machine. For
the programmer, it is using a different syntax, but the machine sees
no difference. And since, in the end what programmers do with their
code is running it on a machine, what a machine sees is what counts,
at least for me.

Edward

On 22/06/2016, Irrwahn <irrwahn@???> wrote:
> On Wed, 22 Jun 2016 12:35:22 +0100, Simon Hobson wrote:
>> On 21 Jun 2016, at 18:50, Irrwahn <irrwahn@???> wrote:
>>> Source code is written for humans, not machines! Clarity and
>>> simplicity can help minimize code maintenance cost, and thus
>>> easily outweigh some slight runtime penalty. Whoever has found
>>> himself in a situation where he had to spend a considerable
>>> amount of time trying to grok what some "clever", "manually
>>> optimized" code is supposed to do, knows what I'm talking about.
>>
>> I have no argument with that, or the rest of your response. However, I do
>> think it is important for a programmer working in a high level language to
>> have some concept of how changing (sometimes subtle) in code can impact on
>> performance. I wasn't suggesting manually optimising code - but looking at
>> how different algorithms and code arrangements impact how the end result
>> runs.
>
> You have a valid point there! I was merely trying do discourage
> (novice) coders from using possibly outdated, overly elaborated
> hacks or screwy design patterns in production code, not to hold
> them off from experimenting. I should have made that a bit clearer.
>
>> Having no idea at all - or worse, not giving a s**t - leads to the scourge
>> of "performance by throwing hardware at it".
>
> Sigh, so true. Cold comfort: Thanks to those idiots today we have
> available the equivalent of earlier mainframes the size of
> wristwatches, at the price of a bench calculator; and those who
> know how to write clear and efficient code have a feast.
>
>> I suspect we've all conversed with people who have approximately zero
>> knowledge or interest in how "the greasy bits" of the machine ends up
>> running their code. My first computer came with just 1k of RAM, and
>> sockets for just 8k total. It's surprising what you can do with that !
>
> Absolutely! I might be a bit spoiled, though, as the first
> machine I could call my own came with a whoppin' 64K, part of which
> was actually available for user programs, and it ran at a lightning
> fast 1MHz. I still have it around, BTW, and every couple of years
> I dig it up, somehow adapt it's video output to the consumer AV
> interface of the year to hook it up to some TV, and then surprise
> myself by still being able to recall some 65xx machine code from
> the top of my head. :^)
>
> Regards
> Urban
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>