[PD-dev] strings
Hans-Christoph Steiner
hans at eds.org
Sun Dec 17 00:37:34 CET 2006
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
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
More information about the Pd-dev
mailing list