Re: Internal visibility

[Han-Wen Nienhuys]

On Mon, Jun 9, 2008 at 3:10 PM, Neil Jerram <address@hidden> wrote:
> 2008/6/1 Han-Wen Nienhuys <address@hidden>:
>
>>  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?

I think there is some confusion here.  To me, a string is a sequence
of bytes. When I need higher level behavior (eg. UTF-x handling), I
convert the sequence of bytes appropriately.  Does the insistence on
not providing a const char* interface mean that there are plans to
change the representation dynamically?

> 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.

Sorry, I guess I don't understand. What _is_the assumption for
representing strings in GUILE?

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen