It isn't clear why only offering base-64functionality isinsufficient
Good point. In light of <charconv>-likeconversions maybe base-64 could (or evenshould) stand alone.
This seems deep. Hmmm. Must consider.
On Tuesday, March 19, 2024 at 07:27:08 PM GMT+1, Vinnie Falco via Boost
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.
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. Thanks _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost