guile-user
[Top][All Lists]
Advanced

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

Re: What is the point of bytevectors?


From: Linus Björnstam
Subject: Re: What is the point of bytevectors?
Date: Sat, 12 Sep 2020 12:35:42 +0200
User-agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3

The point is to work with binary data, of which the most common type of C 
strings are one kind.

If you are using libguile in your C code you can use guile strings in your C 
code and pass them around to avoid the encoding/decoding overhead. Or, the 
other way around, expose the procedures that work with whatever C string 
representation your are using to guile.

If your latin1 strings contain unicode data they are not latin1.

-- 
  Linus Björnstam

On Sat, 12 Sep 2020, at 09:49, divoplade wrote:
> Hello guile users,
> 
> I am writing a library mixing some scheme code and C code, and I have
> two options for interfacing C strings:
> 1. Use bytevectors;
> 2. Use strings with byte access semantics (so-called latin-1, which is
> really a misleading name since it will most certainly contain utf-8-
> encoded unicode text).
> 
> From the C side, they have nearly identical APIs, and the conversion
> functions do not transcode anything.
> 
> From the scheme side, however:
> 1. The bytevector library needs to be imported;
> 2. The function names have way more characters to type;
> 3. The bytevector library is missing a lot of text functions (like
> join, split, trim, pad, searching...).
> 
> If the user wants to always manipulate unicode (decoded) strings, using
> either bytevectors or latin-1 strings require transcoding to enter the
> library and to exit the library, so either option is valid.
> 
> But if the user wants to always manipulate utf-8-encoded strings [1],
> using bytevectors is impossible or much more difficult (see points
> above).
> 
> So, why should I ever use bytevectors?
> 
> divoplade
> 
> [1] https://utf8everywhere.org/
> 
> 
>



reply via email to

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