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.