Bryan Jurish wrote:
moin Martin,
On 2007-02-04 00:40:03, Martin Peach martin.peach@sympatico.ca 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