Re: A base64 library?

From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2024-03-20 13:57:45

On Wed, Mar 20, 2024 at 12:29 PM Ruben Perez via Boost <
boost_at_[hidden]> wrote:

> > Yes, but.. I would like a library that handles various types of
> > encoding/decoding with the "same" interface. Encodings that come to
> > mind: base-64, url, html, radix-64, base-16, base-32, custom base-x
> > alphabet table, base-36, base-62, and so on.
>
> As a user, I've never felt this need - I usually need to encode
> something to a particular base or encoding, and I'd like to have a
> component that does it and does it well. As others have pointed out,
> the more general we make it, the less optimization opportunities we
> have.
>
> Aside from URL and HTML, I've found the need for base-64 and base-16
> in my day to day. What use cases do the other cases cover?
>

As an anecdotal counterpoint to Ruben's, I needed base-62 (by choice, for
identifier),
and base-64 of course (in various variants), and ascii-85.

So I'm more in Andrey's camp than a more generic library would suit me
better.
But that doesn't preclude having a more optimized base-64 variant, since
the fact
it's "bit-aligned" (to 6-bits) makes it more open to optimization (SIMD).

I've also looked at aklomp (new to me, thanks for the link Vinnie),
which looks impressive, but sometimes all you want is a small and well
tested impl.
But they claim having a fast non-SIMD variant too (as a fallback), so maybe
good enough?
Anyone who wants to squeeze out the last bit of performance can it directly.
Same way one would use simdjson directly, instead of Boost.JSON. My $0.02.
--DD