Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-03-21 09:30:55


On 3/21/24 11:35, Rainer Deyke via Boost wrote:
> On 19.03.24 19:16, 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. 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.
>
> Depends on what you mean by "same" interface.  I would expect separate
> functions for each encoding with different customization parameters.
> This does not require that the different encodings come from the same
> library; it just requires that they use the same API conventions.  For
> example, this is good (in terms of parallelism, not necessarily in terms
> of the specifics of the API):
>
>   result = base64_encode(source, base64_options::no_padding);
>   result2 = base16_encode(source, base16_options::lower_case);
>
> This is not so good, because it mixes the options of different
> encodings, resulting in potentially nonsensical combinations:
>
>   result = baseX_encode<64>(source, encoding_options::no_padding);
>   result2 = baseX_encode<16>(source, encoding_options::lower_case);
>
>   // The lower_case option is non-sensical for base 64; can this
>   // error be caught at compile time?
>   // result3 = baseX_encode<64>(source, encoding_options::lower_case);
>
> This is just bad, because it sacrifices performance and type safety for
> the dubious flexibility of specifying encoding at runtime:
>
>   result = baseX_encode(64, source, encoding_options::no_padding);
>   result2 = baseX_encode(16, source, encoding_options::lower_case);

I agree. In every case I have, I know exactly what encoding I want in
every instance; using a different encoding or allowing it to be
determined at run time wouldn't make sense. I think, runtime
configurability is a rare use case, enough to maybe provide it as a
separate layer on top of the specialized algorithms, if at all.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk