The one problem I can think of here is that you can only have 19 bits
of precision in Pd's 32-bit t_float. So having a length of 32 bits
would cause problems if trying to deal with string length using
t_floats. I could see this happening in a loop in Pd space, for example.
.hc
On Dec 16, 2006, at 5:12 PM, Martin Peach wrote:
I think it would be most efficient to have a string type be a
length followed by that many unsigned chars, similar to a Pascal
string but with the length being something like a 32-bit integer.
It would not be added to pd's symbol list. The atom whose type was
string would have to contain a pointer to the first byte of the
string, and a length. Multibyte characters would just be counted as
multiple characters when calculating the length, so the length
would be the number of bytes in the string, not the number of
characters.
It looks too easy to me...In m_pd.h, add:
A_STRING
to t_atomtype.
Add
t_string * w_string;
to t_word.
Add the typedef:
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;
...so a string atom would have a_type = A_STRING and a_w =
a_w.w_string, which points to a t_string containing the length and
a pointer to the string.
If pd is otherwise able to handle atom types it doesn't know about
(?), all the string manipulation objects could be built as externals.
Martin
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
