Am Donnerstag, 27. Juli 2006 20:27 schrieb chromatic: > When embedding or extending Parrot through the external API, most of the > strings go into and come out of Parrot as the type Parrot_STRING. This is > painful and somewhat tedious from C (where these are usually -- but not > always -- C strings already), and it has implications for memory management > (do you use const_string()? Create a new Parrot_STRING through a > function?). > > Where possible, the external API should take and receive C strings.
The distinct STRING* or Parrot_STRING* (in extend) type doesn't make much sense at all. It's a full-blown unicode-capable type and much more complicated than a plain PMC. And it's not a light-weight low-level type at all, despite of some explanations and docs. I was proposing the following already: * STRING arguments use a String PMC - gets rid of one extra indirection in the String PMC - removes a lot of duplicate code with STRING vs. (String) PMC args - all our dynamic HLLs except Perl6 don't have a notion of 'str' anyway and are using a *String PMC * the current S register type becomes a C-string - this is matching Perl6 'str' type (a buffer of 'short' ints) - hopefully - it's nicely covered and optimizable by libc's string functions my 2c leo