Bryan Jurish wrote:
moin Martin,
On 2007-02-04 00:40:03, Martin Peach <[EMAIL PROTECTED]> appears
to have written:
Bryan Jurish wrote:
at any rate, a thousand thanks for your work, and I'm looking forward to
playing with real strings in pd!
Good to know I've done something useful for once!
I guess my question now is whether it's best to have a single [str]
object with lots of selectors for different functions a la [list] as I
did in str.c, or a bunch of objects like [str_join] [str_split] all in a
str library, or individual objects in "flatspace".
I myself am partial to multiple objects, for semantic and
coding-aesthetic reasons, but I can see that the parallel to [list]
could be a motivation for the single-object approach. As to the
question of library vs. a flat collection of single-object externals, I
suppose the question is just how much of a common codebase would the
various objects need? you could also even make multiple build targets
(ext13 style) for the library and the flat collection, leaving the
choice up to the user...
The only common codebase is what's exposed in m_pd.h and implemented in
the patch, which is the minimum that enables pd to pass strings through
inlets and outlets. How you allocate and destroy string space and how
big the strings are is up to you, so you need to take that into account
when processing string messages. IOW the string atom itself only
contains a pointer to the string data, pd doesn't know anything about
the data itself. In the [str] object I found it easier to use a common
set of functions for the various selectors than to repeat them once for
each type, but I think it would be too constraining to force everyone to
use those (basically just the allocation and freeing of the string data).
I also experimented with dynamically resizing the strings using
resizebytes, but found that it would inevitably crash pd, so I settled
on allocating a large block for each string and using a private variable
to hold the current length of the string.
Martin
_______________________________________________
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev