Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Ludovic Courtès escreveu:
>>>> 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?
>>
>> Strings in Guile will eventually be sequences of Unicode code points (as
>> opposed to "bytes"), which can be represented in a variety of different
>> ways (UTF-8, UCS-4, etc.). How Guile represents strings and whether
>> this representation "changes dynamically" (as you suggested) should not
>> be exposed to the applications in order to leave as much freedom as
>> possible to Guile's implementation strategy.
>
> I think that a sequence of Unicode code points this is a somewhat
> limited view of how strings should be used. Among others, the
> implication is that programs cannot rely on being able to index a
> string in O(1) time (since the string might be UTF-x encoded).
>
> What do I use if I want to have guaranteed O(1) indexing -that is- if
> I want to manipulate strings of bytes?
>
> How would I read the contents of a binary file without jumping through
> encoding hoops?
Uniform byte vectors. If you're using C you can just read everything
into a normal C array and then use
scm_take_u8_vector()/scm_u8vector_elements().
--
thehurdguy: LOL you'll end up being like that urban myth
thehurdguy: the guy that thinks he's orange juice
thehurdguy: I'll be like "dude, I know a lisp programmer who did
so much acid, he thinks he's an empty list..."
