[chuck-users] implementing a set (was object / class hacking)

Robert Poor rdpoor at gmail.com
Wed Sep 30 16:12:33 EDT 2009


To clarify: I'd like to implement a set for storing a collection of  
homogenous objects.  Specifically, I need to be able to test for the  
presence of an object in the set, add an object to the set (if not  
already present), delete a object from the set, and iterate over all  
the objects in the set.  This last requirements, sadly, eliminates  
Chuck's "associative arrays".

It's worth pointing out that:

	arbitraryobject.toString()

will generate a string of the form "ClassName:hexLocation".  Assuming  
that Chuck NEVER (ever) relocates a live object in memory (Chuck has a  
reference counting GC, not a copying GC, true?), that string could be  
useful as a unique ID.  But Chuck lacks the string operations to  
reduce a string into a hash key.

So what I'll probably end up doing is to create a unique ID for each  
of my objects (either via toString() or some other construction-time  
device), and keeping the objects sorted in an array using the ID for a  
binary search function.  It's not as fast as a hashmap, but it's  
faster than linear search.

- rob

On 30 Sep 2009, at 12:30, Andrew C. Smith wrote:

>> A check check in the source codes suggested chuck is using std::map  
>> for the
>> associative array part. Then it is just to export to the chuck  
>> language
>> iterator type and functions begin(), end().
>
> Right, but as I understand it Robert wanted to use an array of
> Objects. It seems that the associative array only works to associate
> strings with values, so (for example) you couldn't do:
>
> int foo[0];
> 1 => foo[Bar bar];
>
> because the associations can't take an Object. You'd be left with
> creating a symbolic string for every created Object, rather than
> having an array of Objects that you could search through. Iterating
> over the array seems so fast (especially if they're sortable) that
> throwing a bunch of strings into the mix would be tough.
> Side thought:
>
> class ObjectString {
> Object foo;
> string bar;
> ...(set, get, whatever)...
> }
>
> ObjectString hello;
> Object @ null;
> Object m[0];
>
> SinOsc sine => hello.foo;
>
> hello.foo @=> m[hello.bar];
>
> ...
>
> null @=> m[hello.bar]; // removes object
>
> So that then if you want to know if you have your object (hello), you
> can just ask if m[hello.bar] != null. I'm not sure whether this code
> will work or not, though, and all calls would have to be explicit (not
> iterative--so you couldn't set all m[] Objects to a particular
> parameter, I believe).
>
> Also, the array doesn't seem to be a contiguous block of memory now
> that we have operators << and popBack() and other dynamic array types.
>
> I remembered, .size() is a get method pretty much like .cap(), but
> .size(int) is a set method. Maybe .cap() is vestigial?
>
> Andrew (thanks, Hans, for catching how I only sent this to you)
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users




More information about the chuck-users mailing list