[PD-dev] string external & usage count

[Bryan Jurish]

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