• State Not Answered
  • Replies 68 replies
  • Subscribers 18 subscribers
  • Views 11768 views
  • Users 0 members are here
Options
Related

pointers in Monkey C - bug or by design?

_psx_
over 3 years ago

this code

function f(arr)
    {
        arr[0]=11;
        arr[1]=12;
        arr[2]=13;
    }

    function test()
    {
        var x = [1,2,3];
        SYS.println(x);
        f(x);
        SYS.println(x);

    }

produces in console:
[1, 2, 3]
[11, 12, 13]

It means that f  modified external var x. Is it by design or bug?

sdk 4.1b, 4.0.6, 4.0.5...
eclipse CIQ plug in: 4.1.0.beta1
eclipse ver: 2021-09 (4.21.0) Build id: 20210910-1417
windows 10
minSdkVersion 2.4.0
java jre1.8.0_311

  • 0 over 3 years ago in reply to FlowState

    I wasn't saying you weren't.

    FlowState said:

    But in *one specific case*, it's not true.

    sizeof(x), in the same compilation unit as x, is actually the size of the array and not the size of the pointer.

    Because x is not a pointer.

  • 0 over 3 years ago in reply to FlowState

    And it proves my point that the phrases "pass by value" and "pass by reference" are context dependent and ambiguous.

  • 0 over 3 years ago in reply to dpawlyk

    But every time I agree with you, you post something that sounds like you're contradicting me. Anyway it's all good.

    Also if Garmin is reading this, these forums are terribad. If you're replying to a comment which is subsequently edited, your reply is thrown away.

    Just horrible UX.

  • 0 over 3 years ago in reply to FlowState

    Like I said I think we're just arguing semantics here, but we agree on how everything works.

  • 0 over 3 years ago in reply to dpawlyk
    dpawlyk said:
    Because x is not a pointer.

    I know that. But in most contexts, x is the same as &x[0].

    That was my point. As you pointed out, to a C function that receives x as an arg, x and &x[0] are indistinguishable.

    And if you access x in a *different compilation unit*, it will actually be a pointer. (With sizeof(x) equal to size of(void *))

  • 0 over 3 years ago in reply to FlowState
    FlowState said:
    But every time I agree with you post something that sounds like you're contradicting me.

    I'm not disagreeing with you.

    FlowState said:
    I know that. But in most contexts, x is the same as &x[0].

    I have no doubt you know that. The problem is that how you are explaining it isn't clear enough.

  • 0 over 3 years ago in reply to dpawlyk
    dpawlyk said:
    The problem is that how you are explaining it isn't clear enough.

    That's fair enough.

    As I tried to say:

    - In the context of the same compilation unit, x is an array (e.g. sizeof(x) is the size of the array)

    - In the context of a different compilation unit, x is a pointer to the first element of the array (sizeof(x) is the size of a pointer to the first element of the array)

    And when passing x into a function, x is indistinguishable from &x[0].

    Honestly it's almost midnight where I am, I don't really feel like being more precise or formal than that. Sorry I haven't been communicating well in this thread.

  • 0 over 3 years ago in reply to FlowState
    FlowState said:

    - In the context of the same compilation unit, x is an array (e.g. sizeof(x) is the size of the array)

    - In the context of a different compilation unit, x is a pointer to the first element of the array (sizeof(x) is the size of a pointer to the first element of the array)

    In the first, the name refers to a block of memory (which has a location and a extent) and the compiler treats the name (at times) as an alias to the address of the first element

    In the second, the other place (inside the function) only sees a memory address value (which is the first address of an  "unknown" number of blocks).

    In the call to the function, the compiler replaces the name with the value of the address of the first element (it's not an array being passed).

    (I'm saying the same thing as you did but more clearly. Hopefully!)

  • 0 over 3 years ago in reply to FlowState
    FlowState said:
    To further my point, you believe that arrays are "passed by reference in C#, and you claim that the statement "arrays are passed by value in C#" is *incorrect*, when various sources (including Microsoft itself) either imply or outright state that *array references are passed by value* in C#.

    The MS link shows that arrays are passed as references in true functions and as reference in lambda functions (I think that's what they are called), the thing with the "=>".

  • 0 over 3 years ago in reply to dpawlyk

    Thanks, I do appreciate the clarification.

    I never should've said "arrays are passed by value in C", for sure. I see now that I wrongly implied that an array itself is ever passed into a function in C, which is obviously incorrect, as it's only the pointer that's passed in.

    I will say that in the JavaScript stackoverflow discussion linked above, people said that "arrays and objects" are "passed by value", but they clarified that they meant "a reference to an array/object" is "passed by value". (In this context, when they say "pass by value", they mean that the function can't modify the parameter itself -- i.e. they're not talking about the type of the parameter itself: pointer/reference vs value.)

    Ofc there's another stackoverflow discussion which refers to "passing C structs by value" in which case they mean that someone is trying to pass in a whole copy of a struct in an arg -- in this case "pass by value" clearly refers to the fact that the parameter is a value type vs a pointer.)

    Which illustrates that "pass by value" can have 2 very different meanings.