Thomas Grill wrote:
Hi Martin, many thanks for your initiative, it is greatly appreciated! It would be extremely useful to also define some API for string handling right from the start, to be able to use the string type in externals... all those functionality that seems to be contained in your str object.
:) Part of the patch adds lines to m_pd.h to give a basic API:
A t_string is defined: typedef struct _string /* pointer to a string */ { unsigned long s_length; /* length of string in bytes */ unsigned char *s_data; /* pointer to 1st byte of string */ } t_string;
...and a w_string is added to t_word:
t_string *w_string; } t_word;
t_atomtype is extended with A_STRING: A_STRING } t_atomtype;
and the public functions are prototyped: EXTERN t_symbol s_string; #define SETSTRING(atom, st) ((atom)->a_type = A_STRING, (atom)->a_w.w_string = (st)) EXTERN t_string *atom_getstring(t_atom *a); EXTERN void pd_string(t_pd *x, t_string *st); EXTERN void outlet_string(t_outlet *x, t_string *st); EXTERN void class_addstring(t_class *c, t_method fn); #define class_addstring(x, y) class_addstring((x), (t_method)(y))
The [str] object contains the other functions, you can see them in str.c in /externals/mrpeach/str. Should they be public? I was thinking of an object like [list] which has selectors for various functions. Of course, any external can use t_strings once they are supported by pd. Some other issues are lying around, such as what is the largest possible string. I used MAXPDSTRING but I think that there should be no limit -- string objects should be ready to handle strings that are longer than they have memory for, without crashing. In the str object the s_length field holds the available memory and a separate private field holds the current length, but when passed as an atom through an outlet, s_length contains the true length of the string.
Martin