[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Internal visibility
From: |
Neil Jerram |
Subject: |
Re: Internal visibility |
Date: |
Mon, 9 Jun 2008 19:10:23 +0100 |
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?
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
- Re: Internal visibility, Neil Jerram, 2008/06/01
- Re: Internal visibility, Han-Wen Nienhuys, 2008/06/01
- Re: Internal visibility,
Neil Jerram <=
- Re: Internal visibility, Han-Wen Nienhuys, 2008/06/09
- Re: Internal visibility, Ludovic Courtès, 2008/06/10
- Re: Internal visibility, Thien-Thi Nguyen, 2008/06/10
- Re: Internal visibility, Ludovic Courtès, 2008/06/10
- Re: Internal visibility, Thien-Thi Nguyen, 2008/06/11
- Re: Internal visibility, Ludovic Courtès, 2008/06/11
- Re: Internal visibility, Mike Gran, 2008/06/12
- Re: Internal visibility, Ludovic Courtès, 2008/06/23
- Re: Internal visibility, Han-Wen Nienhuys, 2008/06/11
- Re: Internal visibility, Ludovic Courtès, 2008/06/11