On Sun, 17 Dec 2006, Martin Peach wrote:
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.You make them work as strings when they can, and You make them work as symbols when they must.
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.
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.
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.
Man, that's not n atom type.
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.)
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.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
_______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
