What I’ve been doing I’ve been spending a lot of time working on optimizing the parser; perhaps a bit too much. Nevertheless, it’s very enjoyable and in doing so I’ve learned more than I could hope to ever learn in school. In addition to the optimization, comment and trailing comma support finally got merged, and I implemented UTF-8 validation (enabled by default, but it can be disabled). UTF-8 validation Prior to implementing this extension (or rather, feature which can be disabled), the parser considers any character appearing within a string to be valid, so long as it wasn’t a control character or formed an illegal escape. While this is fast, it technically does not conform to the JSON standard. As per Section 2 of the JSON Data Interchange Syntax Standard: A conforming JSON text is a sequence of Unicode code points that strictly conforms to the JSON grammar defined by this specification. As with most standardese, this particular requirement for conformance is not outright stated, but rather implied. Anyways, that’s enough standardese talk for this post. After working on this parser so much, I’ve pretty much got the suspend/resume idiom we use nailed down, so integrating it with the string...

Overview I’ve been very busy these last two months getting Boost.JSON ready for release, hence the combined blog post. Now that things are winding down, I hopefully can get back the normal blog release schedule. Boost.JSON Aside from a couple of personal projects, the vast majority of my time was spent getting Boost.JSON set for release. Breaking it down, this consisted of three main tasks: a tag_invoke based value conversion interface, parser optimizations, and support for extended JSON syntax. Value Conversion Our previous interface that allowed users to specify their own conversions to and from value proved unsatisfactory, as it required too much boiler-plate when specifying conversions to and from non-class types (e.g. enumeration types). To remedy this, I was tasked with implementing an ADL solution based on tag_invoke which greatly reduces the amount of boiler-plate and provides a single, straightforward way to implement a custom conversion. For example, consider the following class type: struct customer { std::string name; std::size_t balance; }; To convert an object of type customer to value, all you need is to write an overload of tag_invoke. This can be implemented as an inline friend function within the class definition (thus making it visible to ADL...

Boost 1.74 - Interesting Developments in Asio We’re currently beta-testing Boost 1.74, the lead-up to which has seen a flurry of activity in Asio, which has impacted Beast. Recent versions of Asio have moved away from the idea of sequencing completion handlers directly on an io_context (which used to be called an io_service) towards the execution of completion handlers by an Executor. The basic idea being that the executor is a lightweight handle to some execution context, which did what the io_context always used to do - schedule the execution of completion handlers. The changes to Asio have been tracking The Networking TS which describes a concept of Executor relevant to asynchronous IO. The Unified Executors proposal unifies the concepts of io execution and the general concept of “a place to execute work” - a somewhat more generic idea than merely an IO loop or thread pool. Work has been ongoing by the members of WG21 to produce an execution model that serves all parties’ needs. Courtesy of an incredible effort by Chris Kohlhoff, Latest Asio and Boost.Asio 1.74 has been updated to accommodate both models of executors, with the Unified Executors model being the default. It’s important to note...

Overview Greetings, and welcome to my first blog post at The C++ Alliance. I’ve recently begun working on an interesting project for the Alliance which might also have more widespread applicability. The same requirement could possibly apply to your organization as well. Consider an open-source project that has multiple contributors who are submitting changes via pull-requests in Github. You’d like to have assurances that a pull-request passes all tests before being merged. That is done with continuous integration solutions such as Travis or Circle-CI, which are quite popular and well-known. Similarly, if the submission is documentation, you would like to be able to view the formatted output in it’s final published format so you can review the layout, the colors, and so on. What would be the best way to build and publish documentation from pull requests? Perhaps the first thought would be to include the functionality in Travis or Circle-CI. And that is certainly possible. However, in some cases there may be sensitive passwords, ssh keys, or other tokens in the configuration. Is it safe to allow random pull requests, from conceivably anyone on the whole internet, to trigger a Circle-CI build that contains authentication information? Let’s explore that...

Overview Boost 1.73.0 has been released! Save for some minor documentation issues, Boost.StaticString enjoyed a bug-free release, so most of this month was spent working on Boost.JSON getting it ready for review. Unfortunately, I could not spend too much time working due to school and final exams, but now that those have passed I’ll be able to put in significantly more time working on projects such as Boost.JSON. Boost.JSON A good portion of my work on Boost.JSON was spent updating the documentation to reflect the replacement of the storage allocator model with boost::container::pmr::memory_resource (or std::pmr::memory_resource in standalone). The old model wasn’t necessarily bad, but using memory_resource permits the use of existing allocators found in Boost.Container/the standard library, eliminating the need for writing proprietary allocators that only work with Boost.JSON. Even though storage will be going away, storage_ptr will remain to support shared ownership of a memory_resource – something that polymorphic_allocator lacks. As with polymorphic_allocator, storage_ptr will still support non-owning reference semantics in contexts where the lifetime of a memory_resource is bound to a scope, giving users more flexibility. I also worked on monotonic_resource, the memory_resource counterpart to pool. This allocator has one goal: to be fast. I ended up adding...