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

[Stefan Monnier]

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

Agreed.  Unibyte strings are basically byte-arrays whereas
multibyte-strings are char arrays.  In your case you're dealing
with bytes rather than with chars so it makes more sense (to me)
to use unibyte strings.

> >                                            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 think it's worse than that.  `aset' on a multibyte string is very
difficult to support in the case where you replace a char with another
of a different byte-length: it ends up allocating a whole new string.
This is really bad.  I think `aset' on strings should simply be disallowed
(I have it disabled here).


        Stefan