On Mon, Jun 9, 2008 at 3:10 PM, Neil Jerram <[EMAIL PROTECTED]> wrote: > 2008/6/1 Han-Wen Nienhuys <[EMAIL PROTECTED]>: > >> 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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
