[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Internal visibility

From: Han-Wen Nienhuys
Subject: Re: Internal visibility
Date: Mon, 9 Jun 2008 22:51:39 -0300

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 -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]