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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users