Re: Internal visibility

["Neil Jerram" <neiljerram@googlemail.com>]

2008/6/1 Han-Wen Nienhuys <hanwen@xs4all.nl>:

>  const char* ptr = scm_i_string_chars(scmval);
>  string x(ptr);
>
> is the most straightforward and efficient way to create a string.
> Using the API incurs an additional malloc, memcpy and free.

Does "string x(ptr)" incur a malloc and memcpy?

I assume it must do, or else the code above would be unsafe (sharing
memory between the C++ and SCM strings).  So, assuming it does, why do
you think this is Guile's problem, and not C++'s?

To put it another way: can you use another form of C++ string
construction that does not do a malloc/memcpy itself, but takes
ownership of the char * that is passed to it?  Then you could use this
together with scm_to_locale_string(), and you'd still only have one
malloc/memcpy overall.

Guile's string API is aiming not to be 8-bit-assuming, and I would
guess from the code above that the C++ string class is 8-bit-assuming.
 Therefore, in the sequence

   SCM   ->   char *    ->    string

it makes sense to have the malloc/memcpy between SCM and char *, not
between char * and string.

More generally, as regards cases where people are currently using
scm_i_string_chars(), I can imagine that there are good reasons why -
e.g. searching for a particular character or substring.  But I think
we should be aiming to encapsulate those uses in new APIs that will
still work when Guile has non-8-bit strings.

Regards,
       Neil