Re: [boost] A base64 library?

19 Mar 2024


      On Tue, Mar 19, 2024 at 1:26 PM Vinnie Falco  wrote:
...
On Tue, Mar 19, 2024 at 11:17 AM René Ferdinand Rivera Morell via
Boost  wrote:
...
Yes, but.. I would like a library that handles various types of
encoding/decoding with the "same" interface.
...
url
...
Hmm.... I disagree. There are often unique qualities of an encoding
that complicate creating a generic API. For example, with
URL-encoding, there is the concept of the "reserved set." That is, the
set of characters for which escaping is required. Different parts of a
URL have different reserved sets. The target for example reserves the
forward slash (among other things). The query reserves the hashtag '#'
but not the forward slash.
On the other hand base64 has no concept of reserved sets as it
operates on unsigned integers of arbitrary bit width. One is a numeric
encoding, the other is a character encoding.
Understood.. But having a generic API that models the reserved context
independent of the encoding would allow composition of the encoder for
url-target, query-target, host-target, etc.
...
...
If it's more than base-64, yes, it could be a Boost library.
It isn't clear why only offering base-64 functionality is
insufficient. In fact, as a proponent of "modular boost" surely you
see value in isolating each radix to its own library.
Yes :-) But I was also thinking that a user is more likely to use a
library if it overcomes the download "cost". If it's just base64 they
are more likely to either write their own (by copy-pasting from
somewhere) or use some single header standalone library instead of
reaching for the Boost solution.


-- 
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net