v0.2 "Gonzales"

This release is primarily focused on improving runtime performance. The benchmarks at https://github.com/gaspardpetit/base64 showed that cppcodec was lagging many other base64 implementations, subsequent profiling and disassembly tracked this down to a high amount of consecutive integer comparisons. If I wanted better performance, I needed lookup tables. On the other hand, hardcoding bi-directional lookup tables for each variant seemed error-prone and would increase maintenance efforts.

Better performance

The result is a significant refactoring of internals that's several times faster than v0.1 and involves even more intricate template magic, with reverse lookup tables generated at compile time and a few other tweaks. Improvements benefit all codec variants.

In the best case (GCC >=7.0 Release builds), cppcodec is now on par with the fastest competing implementations that offer error checking on decode(). In the average case (other compilers and/or MinSizeRel builds), the runtime is generally within 3 times of the best case. The worst case are Debug builds, where you should not expect anything close to acceptable performance, due to the abstractions involved and the lack of code inlining. Release builds tend to offer the best performance for a given compiler, all three supported compilers (GCC, Clang, MSVC) are now automatically smoke-tested for performance, in addition to correctness, by the continuous builds on Travis and AppVeyor.

Note that cppcodec is now competitive with many other implementations, but still can't compare to highly optimized implementations that use vector instructions (such as this SIMD-accelerated one) or buy better performance with larger pre-computed tables (such as Chrome's base64 implementation). That in addition to the compilers' difficulty with optimizing templates. Keep in mind that performance is still only a secondary goal for cppcodec, the primary goal remains ease of use with a consistent, flexible API.

Less compiler warnings

The other main focus area of this release was to reduce compiler warnings for stringent warning levels. cppcodec will not produce warnings on GCC and Clang with -Wall -Wextra -pedantic, MSVC on VS2017 will be warning-free with /W4. (MSVC on VS2015 has a few warnings left, that's a compiler bug and there wasn't a straightforward solution so I decided not to spend more effort on those. Upgrade to VS2017 if you need them gone.)

The included copy of Catch (the unit test framework) was updated to 2.3.0. This also results in less warnings. If you want to test cppcodec with the installed Catch package, that version is now the minimum required one. If you're just a regular user, you don't have to care about this and can rely on Travis and AppVeyor to test things.

Please stop using "default" includes

Lastly, the use of "default" includes that predefine a shorter class name for the codec (e.g. #include "cppcodec/base64_default_rfc4648.h") is now not recommended anymore. I may deprecate it in the future. It wasn't a good idea in hindsight but many people use it now. If you use these includes in your code, please switch over to the standard includes without "default" (e.g. #include "cppcodec/base64_rfc4648.h"). If you like, you can use a using base64 = cppcodec::base64_rfc4648; declaration in *.cpp files only. Existing headers won't be removed but no new ones will be added.

Acknowledgements

Thanks and kudos go out to @thrimbor, @GTValentine and @ndusart for their code contributions to this release (all related to eliminating compiler warnings), to @SoapGentoo for testing the Catch update, and to everyone reporting bugs and bringing up ideas in the issue queue. cppcodec is doing better because of you.

Initial release

cppcodec hasn't had substantial changes for a while, but it also does the job it's supposed to do with a reasonable amount of features. Pull request #37 asked for it to be packaged, so it makes sense to cut an initial release.

Thanks to @thrimbor, @Kronuz, @smasherprog, @kurt-nj, @nigels-com, @jrogers and @SoapGentoo for their contributions to this release, as well as @efidler who responsively helped me out with project admin stuff despite having changed employers. Thanks also to @theodelrieu whose contributions would likely be part of this release if it weren't for me slacking off.

I expect no API-breaking changes for the master branch at tplgy/cppcodec and thus for future releases at this project location. If I merge any breaking changes in the future then I plan to migrate to jpetso/cppcodec instead, where I have admin privileges.