[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