Re: A base64 library?

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2024-03-21 14:57:37

On Thu, 21 Mar 2024 at 15:11, Vinnie Falco via Boost <boost_at_[hidden]>
wrote:

> On Thu, Mar 21, 2024 at 6:51 AM Misha Komarov via Boost
> <boost_at_[hidden]> wrote:
> > Regarding the unified interface, you mean something like this?
>
> If I were writing such I library I would:
>
> * minimize the use of templates
> * place as few function definitions as possible in the headers
> * make the library a compiled lib (NOT header-only)
> * require all input and output passed in contiguous buffers of char
>

I feel compelled to agree with Vinnie here.

Also, the library should contain exactly two functions at inception:

base64::encode
base64::decode

And none of the other "oh but what if we want base 63?". Nobody wants that
or will ever want or need it.
Base64 is mandated in a number of specifications and RFCs.
It is used in these because it allows binary data to be encoded in such a
way that it can be transmitted as 7-bit ascii without causing terminals to
go haywire when printed.

>
> I would not:
>
> * use generic input iterators and output iterators
> * try make everything header-only
>
> This is the philosophy I have adopted ever since writing Boost.JSON.
> Having extensively written libraries both ways I have concluded that
> for most of the domains I work in, the purported benefits of
> templating everything (muh generic algorithm) do not outweigh the
> downsides. I especially don't see the value in templating the input
> and output iterators.
>
> I realize this will come across as an unpopular opinion, given the
> ingrained dogma of writing things "STL style."
>
> Thanks
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>