moin Joerg, moin Tim, moin List,
just some thoughts:
On 13 October 2004 at 16:43:36, joerg piringer appears to have written:
i don't want to use pointers because if i send an invalid pointer to one of my string objects it will most likely crash pd.
... but that's basically what you're doing now (with additional reference counting), or did I misunderstand?
therefore i use handles. the worst thing that can happen is that a wrong handle refers to the wrong string. i made tests with wrong handles and it is quite fail safe.
... or are you actually adding another table-lookup: it ought to be straightforward enough to use literal pointer values (maybe as Tim suggested by (ab)using w_symbol.s_name) and just keep an ID-hash of "valid" ones around, pointing to their reference counts. But if you go this route, you're doing some extra computation anyways...
i also don't want to use lists because my string class is based on cstring (because it shares code with a "text-processor" program i am writing for my pda) and so i'd have to do a lot of converting between list and string and back again just to do one operation. that cannot be effective.
it's a bit of processing overhead, that's certainly true; and my existing message<->list conversion routines are pretty ugly at the moment (lots of unnecessary re-allocation), but I haven't noticed them slowing me down, even in pretty hefty usage ... of course, I deal mostly with many rapidly changing short strings (English words), and if you're dealing with large chunks of data, your mileage may vary...
conversion would also be additional code to call, but if we have a general convention for string-handling, this could conceivably be packed into a library and (statically) linked in, right?
i also don't know how pd handles lists, does it copy a list when i connect two objects to one outlet? or reference counting?
none of the above, as far as i know: my impression has always been (at least, since some previous hypotheses caused segfaults ;-) that the "originator" (to borrow a term from Frank) of a multi-atom message (i.e. a list) is responsible for allocating and maintaining the memory associated with that list, which can be safely freed when the object itself disappears. So basically, whenever message data gets changed by passing through an object, the object should copy that data into a local buffer, and pass the (modified) local copy back out -- again probably not what you want if you're dealing with large chunks of shared data: maybe pdp would be the way to go in that case.
marmosets, Bryan