|
Boost : |
From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2024-03-21 08:35:30
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_at_[hidden])
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk