I think you can pretty much say that ChucK follows Java's attitude towards objects, where the declaration of any non-primitive always contains a pointer to the memory where the object's data is stored, as opposed to containing the acual values. That's why this doesn't compile:

class A {
        int x;
}

A a1;
1 => a1.x;
A a2;
a1 => a2;
2 => a2.x;
<<< "a1.x=", a1.x, " a2.x=", a2.x>>>;

Hailstone:~ stefanblixt$ chuck test.ck
[test.ck]:line(8): cannot resolve operator '=>' on types 'A' and 'A'...
[test.ck]:line(8): ...(note: use '@=>' for object reference assignment)

After I've put the @ in there as the error message suggests, I get this output from the program:

a1.x= 2  a2.x= 2 

To create copies of an object you need to actively make a method in that class that takes an instance as input, creates a completely new instance, copies each member and then returns the new instance. There is no copy constructor. See Java's clone method in java.lang.Object.

Comparing with C/C++, there you can declare a struct/class variable that isn't a pointer but rather contains all member data where it was declared, allowing you to do crazy stuff like this:

#include <stdio.h>

struct {
int x;
} a1;
struct {
int x;
} a2;

int main(char** argv) {
        a1.x = 1;
        a2.x = 3;
        *(&(a1.x) +4) = 2;
        // this may print "a1.x=1 a2.x=2" if the alignment is correct
        printf("a1.x=%d a2.x=%d\n", a1.x, a2.x); 
}

The confusing bit in ChucK is that it allows declarations with or without a @ before the variable name. My interpretation of this is that

A a;

should be seen as a kind of shorthand for this:

new A @=> A @ a;

These two staments are identical, I think.

/Stefan

 

On Sun, Oct 4, 2009 at 8:57 AM, Hans Aberg <haberg@math.su.se> wrote:

On 4 Oct 2009, at 02:21, Adam Tindale wrote:

This is a more direct version of what I meant to say. The problem I
encountered was that I was hoping to do some operations in a function
and was hoping that I was passing a copy of an object, much like what
happens with primitives. Since objects pass by reference then weird
side effects and bugs can easily creep into a fellow ChucKist's code.

Yes, that is one side effect of it: side effects. The reference objects reference the same object on the heap, also when passed into a function.


Anyways, I hope this example is more clear.

--art

class test{
  0 => int val;
}

test obj1;
<<< obj1.val , "original object">>>;

fun void testclasspassing(test i)
{
  4 => i.val;
  <<< i.val, "in function" >>>;
  // side effect!
}

testclasspassing(obj1);
<<< obj1.val , "original object">>>;

So one way to think about it, is that this is the same as C/C++
 void fun void testclasspassing(test* i) {

   4 => i->val;
   <<< i->val, "in function" >>>;
   // side effect!
 }
which in C++ can also be written as

 fun void testclasspassing(test& i)
 {
   4 => i.val;
   <<< i.val, "in function" >>>;
   // side effect!
 }
only that in chuck, the extra reference symbols are hidden away by the implementation of the reference object.

So when mutating the object within the function, as it is a reference to an object on the heap, it will be mutated there too.

By contrast, when one has a copy over type, a copy will be made, which will placed in the function stack. So when changing that within the function, that is a copy, and not the original object.

 Hans



_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users



--
Release me, insect, or I will destroy the Cosmos!