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
