Re: A base64 library?

From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2024-03-19 18:31:05

 > 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 <boost_at_[hidden]> wrote:  
 
 On Tue, Mar 19, 2024 at 11:17 AM René Ferdinand Rivera Morell via
Boost <boost_at_[hidden]> 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.

> 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