On Wed, Mar 20, 2024 at 12:29 PM Ruben Perez via Boost < boost@lists.boost.org> 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