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); -- Rainer Deyke (rainerd@eldwood.com)