Re: struct.el -- a package to encode/decode binary data

[Kim F. Storm]

Eli Zaretskii <address@hidden> writes:

> On Thu, 21 Mar 2002, Richard Stallman wrote:
> 
> > Is there some specific reason not to use unibyte strings here?
> 
> They are simply not needed here (AFAICS). 

On the surface, it looks "obvious" to use unibyte strings for
data which is known to be - and processed as - byte-oriented
data.

But I guess you are right that it isn't strictly necessary even for
byte-oriented data, so I will avoid the final conversion to unibyte --
if unibyte-ness is really needed, the caller can do the conversion.

I've now changed the struct.el code to operate on a vector instead of
a string, so in my case it really doesn't matter anymore.

>                                            IMO, unibyte strings
> should not be used unless absolutely necessary, ideally never.

Am I right in assuming that aref, aset, and substring are potentially
much slower on a multibyte string than on a unibyte string?  Probably
not noticeable if you just look at a single char from a string, but
what if you loop over a string (forwards or backwards)?

I can see there is some caching in string_char_to_byte for multiple
accesses to the same string, but it breaks as soon as you operate on more
than one string e.g. in a loop.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk