[PD-dev] strings

[martin.peach at sympatico.ca]

> 
> De: Mathieu Bouchard <matju at artengine.ca>
> Date: 2006/12/18 lun. PM 12:11:18 GMT-05:00
> À: Martin Peach <martin.peach at sympatico.ca>
> Cc: pd-dev at iem.at
> Objet: Re: [PD-dev] strings
> 
> On Sun, 17 Dec 2006, Martin Peach wrote:
> 
> >> You make them work as strings when they can, and
> >> You make them work as symbols when they must.
> > There would be two objects, [stringtosymbol] and [symboltostring] that you 
> > could put between string and symbol objects. Of course some strings would get 
> > impossibly mangled this way but that's because of the way symbols work.
> 
> I have no clue what you're talking about: how mangled would they be? i 
> don't plan any mangling to happen, except for the presence of \0 
> characters.

Maybe you don't understand what is being proposed. How would you make a symbol containing ASCII NUL and CR LF characters for instance?

> 
> > Yes, there's no reason not to have 0-length strings. And no reason to trash 
> > them when they are unused either, since they don't take up more space than 
> > any other object.
> 
> They take the space it takes to tell their size and the pointer to the 
> buffer. That's significant, and nearly as much as in the case of a 
> t_symbol, supposing that those t_strings can live independently of the 
> objects that produce them.

Like any other object strings have that overhead, but unlike lists they only have one atom per string. They would be created by string objects and last as long as the string objects. One string per string object. String messages are passed between string manipulator objects. For this purpose symbols are not usable because they can't contain every possible character and lists have too much overhead since each element of a list is an atom.

> 
> > I'm suggesting that a [string] be like any other object and be 
> > deallocated when the patcher is closed.
> 
> Ok, that's certainly the string feature that I want. It's too much trouble 
> for the benefit.

Whatever.

> 
> Man, that's not n atom type.
> 

No it's not n atoms, it's a single atom that contains a pointer to a list of bytes. That's the main advantage of string over list.

> > Symbols are difficult to work with because their content gets interpreted,
> 
> You say that in answer to my questions on allocation? (That's not an 
> allocation issue and not even any kind of memory layout issue.)

I don't know, did I? It looks to me like an answer to a question about why symbols can't be used to encode arbitrary strings. Maybe I was tired.

> 
> > for example if I write a comment "MP 20061214" it gets converted into "MP 
> > 2.00612e+007"
> 
> the contents of a comment box is not a symbol. It's a list of atoms. 
> However, Pd has the same problem you describe when trying to save some 
> symbols. e.g. say you have a symbol with a space in it and you pass it to 
> a messagebox "set $1" which passes it to an empty messagebox, and then you 
> save the patch: then you have that problem with symbols. But the contents 
> of the comment box has that problem while never storing its contents as a 
> symbol.

I wonder how the list of atoms in a comment box gets by without some of those atoms being symbols...

Martin