On Tue, Mar 19, 2024 at 11:35 AM René Ferdinand Rivera Morell
Understood.. But having a generic API that models the reserved context independent of the encoding would allow composition of the encoder for url-target, query-target, host-target, etc.
Again the benefits are unclear. Creating a generic API is a tradeoff, as it constrains a specific implementation into meeting the requirements of the generic API. This might be ok if all the implementations are largely the same but that becomes less and less true as you add more encodings and especially decodings. For example, the API for an encoder that supports streaming is going to be necessarily different from one that does not support streaming. Trying to abstract the "streaming" feature of the encoder will be an exercise in futility (as I know from experience). The implementation is also going to be different between them, with different performance profiles. The implementation for a decoder which can assume the output buffer has sufficient size looks radically different than when it has to handle the potential for insufficient space. The API also looks different as in how the "insufficient space" condition is communication. Trying to make this generic, is also going to be weird. There are actually two problems proposed here: 1. High-quality implementations of numerical radix conversions (I leave out character encodings since those are really a completely different thing) 2. Designing a generic API for parameterizing radix conversions There is a clear need for 1, but there is little evidence that a Boost-quality solution for 2 exists. A quick search shows no shortage of implementations (that is, solutions to number 1 above) for a pretty good number of different bases. If you believe that a workable generic API exists for encoding and decoding, that is a separate problem that can be approached in terms of design. And you can explore that by downloading and using the already-existing, non-Boost libraries which perform radix conversions and adapt them to your prototyped API. FYI, I have explored the design space of "generic APIs for radix conversions" and those experiments didn't go well. Maybe someone else can show me how it's done...but it seems like the more generic you make the interface the less opportunity you have for something that is optimized for a particular base (like 64 as we are contemplating). Thanks