Introduction I’m a first-year university student at the University of Connecticut pursuing a degree in Computer Science. I joined The C++ Alliance near the end of January as a part-time Staff Engineer at the recommendation of Vinnie, who has been mentoring me for the past several months. I’ve been programming in C++ for around 2 years now, with an interest in library development and standardization. My original reasoning for choosing C++ over other languages was a little misguided, being that it was generally regarded as a difficult language, and I liked the challenge. Prior to this, I had dabbled in the language a little bit, but I really didn’t get into it until I discovered the existence of the standard. A language with explicitly defined semantics, all specified in a document that is difficult to parse sounded very appealing to me, and thus I embarked on my journey to learn everything about it that I could. If you were to ask me what I like most about it now, it would probably be a tie between the “you don’t pay for what you don’t use” principle and zero cost generics. With regard to standardization, I do a lot of standardese bug-fixing in the form of editorial issues and defect reports, and I write papers mostly focused on fixing the language. As for library development, I’m currently working on Boost.JSON and Boost.StaticString, the latter of which has been accepted into Boost. Boost.JSON My work on Boost.JSON originally started with writing a documentation style guide and then applying it to the library. The first place where this documentation was applied to was json::string; a non-template string type similar to std::string, but with a type erased allocator, used exclusively with char. The documentation of json::string proved to be no easy feat, due to its overwhelming number of overloaded member functions (string::replace itself has 12 overloads). Detailed documentation of these functions did prove to be a little tedious, and once I finished, it was clear that a better interface was needed. The standard interface for std::string is bound to a strict regimen of backward compatibility, and thus the interface suffers due to its lack of the ability to remove stale and unnecessary overloads. Take replace for instance: it has overloads that take a string, a type convertible to string_view, a pointer to a string, a pointer to a string and its size, a string plus parameters to obtain a substring and a string_view plus parameters to obtain a substring. All of these overloads can be replaced with a single overload accepting a string_view parameter, as it is cheap to copy, and can be constructed from all of the aforementioned types. Those pesky overloads taking parameters to perform a substring can also be done away with, as the substring operation can be performed at the call site. json::string includes a subview function which returns a string_view for cheap substring operations, so needless json::string constructions can be avoided. With the guidance of Peter Dimov, I drafted up a new string_view based interface, which dramatically reduced the number of overloads for each member function. Once the sign-off was given, it was a relatively trivial task to implement, as it was merely a matter of removing no longer needed overloads, and changing function templates that accepted objects convertible to string_view to be non-template functions with a string_view parameter. Boost.StaticString I was originally invited by Vinnie to work on Boost.StaticString (then Boost.FixedString) back in October, and since then it has been accepted into Boost. It provides a fixed capacity, dynamically sized string that performs no dynamic allocations. It’s a fast alternative to std::string when either the capacity of the string is known or can be reasonably approximated at compile time. My primary objective for February was to implement the post-review changes requested by our review manager Joaquin Muñoz in time for the next Boost release. Most of the changes by this point had already been implemented, but still lacked polish, and the test coverage had to be improved. Additionally, I wanted to add a few optimizations and improve the constexpr support, the latter proving to be quite a daunting task. The nice thing about static_string is that the capacity of the string is part of the type, consequently allowing us to make all kinds of assumptions and to statically resolve what optimizations we want to perform at compile time. In particular, the usual checks are done in insert and replace that determine if the source of the operation (i.e. the string that will be copied into the string) lies within the string the operation is performed upon can be elided if we can somehow guarantee that they will never overlap. Since non-potentially overlapping objects of different types are guaranteed to occupy distinct addresses, we can safely skip this check for overloads accepting static_string parameters, if the capacity of the strings differ. In my opinion, it’s pretty neat. The aforementioned check that is performed in insert and replace also was the source of some serious headaches with respect to constexpr support across implementations. When you mix in the requirement to support C++11, it gets even worse. The primary issue that presents itself is that comparing pointers with the built-in relational operators yield unspecified results when the pointers do not point to elements of the same array; evaluating such an expression is forbidden during constant evaluation. The usual workaround to this is to use the library comparison operators (i.e. std::less, std::greater etc.), and in standardese land, it’s all good and well. However, on actual implementations, this won’t always work. For example, when using clang with libstdc++, the implementation for the library comparison operators casts the pointers to integer types and compares the resulting integers. If __builtin_is_constant_evaluated is available it is used and the check is instead done using the built-in relational operators, but this was only implemented on clang quite recently and therefore cannot be used for the most part. Figuring this out and finding a solution was quite a process, but eventually, I settled on a solution that gave the least unspecified results across implementations, provided good performance, and actually compiled. In essence, if std::is_constant_evaluated or a builtin equivalent is available, we can use a neat trick involving the equality operator for pointers. Equality comparison for pointers almost never has unspecified results, so to check if the pointer falls within a range, we can iterate over every pointer value within that range and test for equality. This is only done during constant evaluation, so performance does not suffer. If the aforementioned functions cannot be used, or if the function is not evaluated within a constant evaluation, we use the built-in comparison operators for configurations where the library comparison operators don’t work in constant evaluation, and otherwise use the library comparison operators. Having a portable version of this check in the standard library wouldn’t be a terrible idea, so it may be something I will pursue in the future. Another feature that took a little bit of time to get working were the to_static_string overloads for floating-point types. static_string does not enjoy the luxury of being able to increase capacity, so sticking to only using standard notation isn’t possible since floating-point types can represent extremely large values. To get the best of both worlds, we first attempt to use standard form and then retry using scientific notation if that fails. To match std::to_string, the default precision of 6 is used for standard form - however, if we resort to scientific notation, we use the highest precision value possible based on the number of digits required to represent all the values of the type being converted, and the number of digits in its maximum mantissa value. As Peter Dimov noted several times, using the %g format specifier would be a preferable solution, so I may change this in the future. Standardization The Prague meeting came and went (I did not attend), and unfortunately no progress was made on any of my papers. CWG was very busy finalizing C++20, so that left no time for a wording review of P1839, and I’m holding off on my other papers. I’m planning to attend the New York meeting in November representing The C++ Alliance (my first meeting, I’m excited!), and is where I will be presenting P1945, P1997, and a few others that are currently in the works. Outside of proposals, it was business as usual; finding and fixing several editorial issues, and filing a few defect reports. Most of the work I do focuses on fixing the core language, and generally improving the consistency of the wording, so this month I worked on fixing incorrect conventions, removing redundant wording, and a small rewrite of [dcl.meaning] on the editorial side of things. As for defect reports, they consisted of some small wording issues that weren’t quite editorial but didn’t have a significant impact on the language. Summary My experience working at the Alliance has been very positive thus far. Being a student, having flexible hours is fantastic, as I am able to adjust when I work based on my school workload. In the short amount of time I have spent working on Boost.JSON and Boost.StaticString, I have learned a lot, and continue to do so every day. Vinnie, Peter, and Glen always provide their invaluable feedback through reviews and answering questions, which is extremely helpful when working on projects of this scale with little experience. I consider the acceptance of Boost.StaticString into Boost to be my crowning achievement thus far, and I’m excited to see what kinds of cool projects I’ll be working on in the future. If you want to get in touch with me, you can message me on the Cpplang slack, or shoot me an email.

The Lesser HTTP Refactor Aside from the normal answering of queries and issues, February has been a month dominated by the difference between the asio::DynamicBuffer_v1 and asio::DynamicBuffer_v2 concepts. As I understand things, both Beast and Asio libraries developed the idea of the DynamicBuffer concept (or more correctly, Named Type Requirement [NTR]) at roughly the same time, but with slightly different needs. The original Asio DyanmicBuffer describes a move-only type, designed to be a short-lived wrapper over storage which would allow a composed operation to easily manage data insertions or retrievals from that storage through models of the MutableBufferSequence and ConstBufferSequence NTRs. In Beast, it was found that DynamicBuffer objects being move-only caused a difficultly, because the necessarily complex composed operations in Beast need to create a DynamicBuffer, perform operations on it, pass it to a sub-operation for further manipulation and then continue performing operations on the same buffer. If the DynamicBuffer as been passed by move to a sub operation, then before the buffer can be used again, it will have to be moved back to the caller by the callee. Rather than complicate algorithms, Beast’s authors took a slightly different track - Beast DynamicBuffers were specified to be pass-by-reference. That is, the caller is responsible for the lifetime of the DynamicBuffer and the callee is passed a reference. This satisfied Beast’s needs but created an incompatibility with Asio and Net.TS. Vinnie Falco wrote a paper on the problem offering a solution to enabling complex composed operations involving DynamicBuffers. On reflection, LEWG took a different view and solved the problem by re-engineering the DynamicBuffer NTR. The result is that Boost.Beast objects are now likely to encounter three versions of DynamicBuffer objects in the wild and needs to be able to cope gracefully. Boost.Asio now has the NTRs DynamicBuffer_v1 and DynamicBuffer_v2, with the NTR DynamicBuffer being a synonym for either depending on configuration flags (defaulting to DynamicBuffer_v2). We have had to go a little further and add a new NTR in Beast, DynamicBuffer_v0. The meanings of these NTRs are: NTR Mapping in Asio Mapping in previous Beast Overview DynamicBuffer_v0 none DynamicBuffer A dynamic buffer with a version 1 interface which must be passed by reference DynamicBuffer_v1 DynamicBuffer_v1 Asio DynamicBuffer (v1) A dynamic buffer with a version 1 interface which must be passed by move DynamicBuffer_v2 DynamicBuffer_v2 none A dynamic buffer with a version 2 interface which is passed by copy My intention this month was to migrate the entire Beast code base to use Asio’s (and current net.ts’s) DynamicBuffer_v2 concepts while still remaining fully compatible with DynamicBuffer_v0 objects (which will be in existing user code). The first attempt sought to change as little of the Beast code as possible, by writing DynamicBuffer_v0 wrappers for DynamicBuffer_v[1|2] objects, with those wrappers automatically created on demand in the initiating function of Beast IO operations. The problem with this approach is that it penalised the use of DynamicBuffer_v2 with an additional memory allocation (in order to manage a proxy of DynamicBuffer_v1’s input and output regions). On reflection, it became apparent that in the future, use of DynamicBuffer_v2 will be the norm, so it would be inappropriate for Beast to punish its use. Therefore, we have chosen to take the harder road of refactoring Beast to use DynamicBuffer_v2 in all composed operations involving dynamic buffers, and refactor the existing DynamicBuffer_v0 types in order to allow them to act as storage providers for DynamicBuffer_v2 proxies while still retaining their DynamicBuffer_v0 public interfaces. I had hoped to get all this done during February, but alas - in terms of released code - I only got as far as the refactoring of existing types. The code has been released into the develop branch as part of Version 286. The refactor of HTTP operations and Websocket Streams in terms of DynamicBuffer_v2 is underway and indeed mostly complete, but there was not sufficient time to release a sufficiently robust, reviewed and tested version this month. I plan to finish off this work in the first part of March, which will hopefully leave time for more interesting challenges ahead. What’s Next Well, the Beast Issue Tracker is far from clear, so there is plenty of work to do. At some point though, I’d like to make a start on a fully featured higher level HTTP client library built on Boost.Beast. We’ll have to see what unfolds.

History This is my first entry on the C++ Alliance web site. I’m very happy to say that I was invited to join the organisation at the end of December last year. I first met Vinnie on Slack when I chose to use Boost.Beast in a greenfield project - a highly scalable market data distribution system and quoting gateway for the Japanese cryptocurrency exchange liquid.com. There were a number of candidates for C++ HTTP frameworks and it is interesting for me to examine the decision-making process I went through in choosing one. If I am honest, there are two main factors that influenced me towards Boost.Beast: I am a long-time fanboi of Boost.Asio. I find it’s paradigm very pleasing. Once you decipher the (extremely terse!) documentation it becomes obvious that it was written by a hyper-intelligent extraterrestrial masquerading as a human being. I have used the Boost Library (or more correctly, libraries) for many years. Boost has become synonymous with trust, quality and dependability. As far as I have always been concerned, boost is the standard. The standard library has always been a pale shadow of it. When I started the new project there was an expectation that I would have a team to work with. In the end, I found myself writing the entire system alone from scratch. Liquid Tap contains two fully-featured web servers (one facing the organisation and one facing the outside world), supports inbound and outbound websocket connectivity (with per-fqdn keepalive connection pooling) and multi-threaded operation. The project took me 3 months from writing the first line of code to full production readiness. I was personally impressed by the speed with which I was able to assimilate a new library and create a fairly complex service infrastructure using nothing more than boost, nlohmann_json, openssl and a c++17 compiler. In my view this would not have been possible without the excellent documentation and careful attention to detail in Boost.Beast. During the development, I reached out to Vinnie and Damian on Slack a number of times. Both were always helpful and attentive. Without a doubt they were instrumental in the success of my project. So here I am in January 2020. Just like the old TV advert where Victor Kayam was so impressed with his electric shaver that, “I bought the company”. I was so impressed with Boost.Beast and its creators that when given the chance, I chose to join the company. First Month I have spent my first month with the firm going through Vinnie’s Boot Camp. It’s been an interesting and invigorating experience. I have many years of experience writing code for production environments, from embedded systems like slot machines and video games to defence to banking and trading systems. I’m fairly confident that if you can describe it, I can write it. But maintaining a publicly-facing library is a new and very different challenge. Controlling the Maintenance Burden C++ is a language in which types are cheap. So cheap in fact that many people (including me) recommend describing any concept in a program as its own type. This is a great way to cause logic errors to fail to compile, rather than fail to impress your customers. But in a library such as Boost.Beast, every public type you create is a type you must document and maintain. If you discover that your type has a design flaw, you’re a little stuck. Any future changes need to be source-compatible with previous versions of the library. Dangerous or incorrect elements in the design must be deprecated gracefully. All this requires careful management. Management takes time. Something I learned from Vinnie very quickly is that for this reason, interfaces to public objects should provide the bare minimum functionality that users can demonstrate a need for. Adding a new public method or class should only happen after careful consideration of the consequences. Supporting all Toolchains Another consideration I have never had to encounter before is that Boost.Beast is designed to work on every compiler that “robustly supports” C++11. In my career as a software engineer I have always demanded (and mostly had) autonomy over the choice of toolset. Of course I have always chosen the very latest versions of gcc, clang and msvc and used the very latest standard of c++ available. Why wouldn’t I? It improves productivity, and who wants to be stuck in the Dark Ages when all your friends are using the new cool stuff? I wrote Liquid Tap in C++17. If C++2a had been more advanced and supported by all compilers at the time I’d have used that, because compiler-supported coroutines would have shortened the code and made debugging and reasoning about sequencing a whole lot easier. Now I find myself thinking about how to support the latest features of the language, while ensuring that the library will continue to function for the many C++11 and 14 users who have not been as fortunate as me and are still constrained by company policy, or indeed are simply happy not to have to learn the new features available in more recent standards. Attention to Detail Boost.Beast strives for 100% (or as close to it as possble) coverage in testing. This is only logical. Users are not going to be happy if they have to continually decipher bugs in their programs caused by us, file bug reports and either patch their Boost source or wait up to three months for another release. In addition, documentation matters. You know how it is in a production system. More effort is spent on content and utility than documentation. Developers are often expected to read the code or ask someone if there’s something they don’t understand. Not so when maintaining a library for public consumption. One of the reasons I chose Boost.Beast was the quality, completeness and accuracy of its documentation. This is no accident. Vinnie and his team have put a lot of time into it. Only now am I becoming aware of what an Herculean task this is. Users will hold you to your word, so your word had better be the Truth, the Whole Truth and Nothing But the Truth. Activities Issue Maintenance This month I have been working through some of the Issue backlog in Boost.Beast. It’s satisfying to see PRs getting accepted and the list of open issues being whittled away. At the moment it’s interesting to see new issues and queries being raised too. I’ll revisit this in next month’s blog and report as to whether it’s still interesting then :) I have also been taking time to liaise with users of the library when they raise queries via the Issue Tracker, email or the Slack Channel. I think staying in touch with the users is an excellent way to get feedback on the quality of documentation and design. It’s also nice to be able to help people. Not something you get time to do very often when working on an FX-options desk in an investment bank. Boost.Json I have been providing some support to the upcoming Boost.JSON library. This library focusses on: Absolute correctness in reference to RFC8259. Seeking to match or exceed the performance of other c++ JSON libraries such as RapidJSON. Providing a clean, unsurprising programming interface and impeccable documentation. This is a fascinating project for me. Various JSON libraries employ various tricks for improving performance. Performance can be gained at the expense of rigorous syntax checking, use of buffers and so on. Achieving the Holy Grail of full correctness, minimal state and absolute performance will be an interesting challenge. Boost.URL Vinnie is also working on Boost.URL. While I have not contributed any code, spending my time in the #beast Slack channel has meant that I’ve been able to keep up to speed with the various design choices being made. Again, there has been much to learn about a design rationale that focuses heavily on the potential maintenance burden. There is actually a lot that could be learned by developers in industry from taking part in or observing this discourse. Work Schedule The C++ Alliance is based on the West Coast of the USA, while I live and work in the tiny Principality of Andorra in mainland Europe. This puts me some nine hours ahead of my colleagues across the Pond. It turns out that this is a perfect way of working for me. I can get up at 8am, nip out for a couple of hours skiing or hiking, enjoy lunch and then get to work - before anyone else in the firm is even awake. I’m a bit of a night-owl anyway, so working later in order to engage in “lively debate” with my colleagues on Slack is no problem. It also means I have a legitmate excuse to get out of any social engagments I don’t want to be bothered with. So for me it’s all win. Summary I’ve really enjoyed my first month. I think Vinnie worries that he’ll nag me too much about seemingly unimportant details like commit message wording and achieving a certain tone in code documentation, but I don’t mind it. Boost.Beast is a fantastic piece of work. It’s Vinnie’s baby, and I am privileged to be asked to hold it in my hands. I’m never going to take issue with a mother looking to protect her cubs. Furthermore, having a legitimate excuse to interact with the other maintainers of Boost on Slack is a pleasure. These people are some of the brightest minds on the planet. I live in hope that some of this brilliance will rub off. If you work with C++, I highly recommend that you join the Cpplang Slack channel. If you’d like to contact me to discuss my experiences I’d be happy to receive a message on Slack. Thanks for reading. Richard Hodges

The Alliance is a Gold sponsor for C++Now 2020. This conference is a gathering of C++ experts and enthusiasts from around the world in beautiful Aspen, Colorado from May 3, 2020 - May 8, 2020.

There are four main areas where I spend my time. Libc++, where I am the “code owner” WG21, where I am the chair of the Library Working Group (LWG) Boost Speaking at conferences Lots of work these month(s) behind the scenes, getting stuff ready for C++20, LLVM 9, and Boost 1.71.0. Libc++ The LLVM 9.0 release has shipped! The release date was 19-September, a few days later than planned. There are a lot of new libc++ features in the release. As the “code owner” for libc++, I also have to review the contributions of other people to libc++, and evaluate and fix bugs that are reported. That’s a never-ending task; there are new contributions ever day. Many times, bug reports are based on misunderstandings, but require a couple of hours of work in order to figure out where the misunderstanding lies. We’re working on a major redesign of the “debug mode” for libc++, after we realized that the existing (not widely used) debug mode is useless when you’re trying to do things at compile (constexpr) time. I have been spending a lot of time the last few weeks working on the calendaring stuff in <chrono>, specifically the interface with the OS for getting time zone information. It is a surprisingly complicated task. Fortunately for me, I have a friend who has been down this road in the past, and is willing to answer questions. LWG issues resolved in libc++ (almost certainly incomplete) LWG3296 Add a missing default parameter to regex::assign LLVM features implemented (almost certainly incomplete) P1466 Parts of P1466 “Misc Chrono fixes” more to come here. LLVM bugs resolved (definitely incomplete) Bug 42918 Fix thread comparison by making sure we never pass our special ‘not a thread’ value to the underlying implementation Bug 43063 Fix a couple of unguarded operator, calls in algorithm Bug 43034 Add a missing _VSTD:: before a call to merge. Bug 43300 Add a missing _VSTD:: Only initialize the streams cout/wcout/cerr/wcerr etc once, rather than any time Init::Init is called Other interesting LLVM bits from (certainly incomplete) Revision 368299 Implement hh_mm_ss from P1466. Part of the ongoing <chrono> implementation work. The current status of libc++ can be found here: C++20 status C++17 status C++14 status (Complete) Libc++ open bugs WG21 We shipped a CD out of Cologne in July. Now we wait for the National Bodies (members of ISO, aka “NBs”) to review the draft and send us comments. When we’ve resolved all of these comments, we will send the revised draft out for balloting. If the NBs approve, then that draft will become C++20. The next WG21 meeting will be November 2-8 in Belfast, Northern Ireland. This will be the first of two meetings that are focused on resolving NB comments; the second one will be in Prague in February. I have several “clean-up” papers for the Belfast mailing. The mailing deadline is a week from Monday (5-October), so I need to finish them up. P1718R0: Mandating the Standard Library: Clause 25 - Algorithms library P1719R0: Mandating the Standard Library: Clause 26 - Numerics library P1720R0: Mandating the Standard Library: Clause 28 - Localization library P1721R0: Mandating the Standard Library: Clause 29 - Input/Output library P1722R0: Mandating the Standard Library: Clause 30 - Regular Expression library P1723R0: Mandating the Standard Library: Clause 31 - Atomics library We polled the NBs before Cologne, and they graciously agreed to have these changes made post-CD. Boost Boost 1.71.0 was released on 19-August. Micheal Caisse was the release manager, with some help from me. As part of the Boost Community maintenance team, I (and others) made many changes to libraries whose authors are no longer able (or interested) in maintaining them. I have a couple of suggestions for additions to the Boost.Algorithms library that I will be working on in the near future. Conferences I was a speaker at CppCon last week. I gave a new talk “std::midpoint - How hard could it be?” (no link yet) which was quite well received. I got a few questions that will require additional research, and may improve my implementation. I also participated in the “Committee Fireside Chat”, at CppCon, where conference members get to ask questions of the committee members who are present. Upcoming talks: LLVM Developer’s Conference is in San Jose in October. I will not be speaking, but I will be moderating the lightning talks. C++ Russia is at the end of October in St. Petersburg. ACCU Autumn is right after the WG21 meeting in early November. Meeting C++ is in mid-November in Berlin. I will be making the “Fall 2019 C++ European Tour”, going from St. Petersburg to Belfast to Berlin before heading home mid-November.

The Alliance is a Gold sponsor for CppCon 2019. This conference is the annual, week-long face-to-face gathering for the entire C++ community. The conference is organized by the C++ community for the community. Attendees enjoy inspirational talks and a friendly atmosphere designed to help individuals learn from each other, meet interesting people, and generally have a stimulating experience.

Boost.Beast I’ve started working on improvements to the zlib part of Beast. There are some gaps in the test harness of these components, so I’ve decided to increase coverage. As a first step, I started porting test cases from the original zlib library’s tests, to verify that existing code matches the expected behavior of the original library. Fortunately, I’ve not found any significant discrepancies, there’s only one issue where Beast rejects malformed input for the wrong reason (I’m still looking into it whether it’s actually an issue at the time of writing this). I’ve also looked into providing more meaningful feedback from test failures in Beast, especially when they’re run in CI. While the current test framework does print a line number on failure, the line number is often in a function template that’s called by multiple test cases, which makes it quite hard to determine which test failed just from the log, often requiring the use of a debugger. Doing that locally may not be a problem, but it’s significantly harder in CI, so I’ve decided to try to use Boost Stacktrace to provide a callstack on each failure in Beast tests. Additionally, I’ve also worked on running the test suite without OpenSSL installed, to hopefully fix some of the failures in the official Boost test matrix. The question of Networking TS and TLS There’s recently been quite a bit of discussion of networking being useless without “secure by default” sockets. Since this is a recurring topic and I expect it to return in the future, so I’ve decided to write up an analysis of this issue. First of all, I believe that an attempt to deliver a “secure by default” socket within the current networking proposal right now will result in something like std::async - not really practically useful. What kind of TLS facilities I’d consider useful for the average user of the standard library? A reasonable guideline, I think, are ones I could trust to be used in a distributed system that handles money (in any form). Note, that TLS is not only a protocol that provides confidentiality (i.e. encryption), but also allows verification of the identity either the server by the client, or both. Remember, doesn’t matter if 3rd parties can’t see what you’re sending, if you’re sending your data to the wrong peer in the first place! While it may seem simple at first look, just verifying the identity of a peer is an extremely complex process, as my experience with Certify has shown. Doing it portably and efficiently with the same interface and effects is extremely difficult. Browsers resort to all kinds of workarounds and custom solutions to be able to securely implement just this one aspect of TLS. I attempted to implement a library (intended for inclusion into Boost) that would perform this one aspect, however, I found it to be impossible to provide a practical solution with the current state of the networking ecosystem in Boost. In fact, one method of certificate verification (via the OCSP protocol) requires a (very) basic HTTP client. Yes, in order to perform a TLS handshake and verify the peer’s certificate status using OCSP, you need an HTTP client. This is just one aspect of the TLS protocol that needs to be addressed. There are others as well - what about the basic cryptographic building blocks, like ciphers, hashing algorithms, PRFs and so on - they are bound to be used in a hypothetical implementation in a standard library, should they be exposed? If yes then with what interface?. Considering that there are no standard networking facilities and not even a proposal for standard TLS, this is a discussion that would essentially postpone standard networking indefinitely. Finally, there’s also an opposite position that no networking should be in the standard at all. I disagree with this position - networking has become a very important part of many C++ projects (in my career, all C++ projects I dealt with, touched some sort of network in one way or another). At the very least we need standard named requirements for library compatibility, since that is severely lacking in the ecosystem at this point.

There are four main areas where I spend my time. Libc++, where I am the “code owner” WG21, where I am the chair of the Library Working Group (LWG) Boost Speaking at conferences This month, the big news (and the big work item) was the approval of the C++ “Committee Draft” at the WG21 meeting in Cologne on July 15-20. You can think of this as a “beta version” of the C++20 standard; all features are complete. The next step is bug fixing, with an eye towards releasing next year. Libc++ The LLVM 9.0 release is on track for September. We have a release branch, and the RC1 was recently dropped. Because of the run-up and the aftermath of the Cologne meeting, the libc++ accomplishments are a bit sparse this month. As the “code owner” for libc++, I also have to review the contributions of other people to libc++, and evaluate and fix bugs that are reported. That’s a never-ending task; there are new contributions ever day. LWG issues resolved this month in libc++ (almost certainly incomplete) LWG2273 regex_match ambiguity LLVM features implemented this month (almost certainly incomplete) P1612 Relocate endian P1466 Parts of P1466 “Misc Chrono fixes” more to come here. LLVM bugs resolved this month (definitely incomplete) Other interesting LLVM bits from this month (certainly incomplete) Revision 365854 Reorganize the <bit> header to make most of the facilities available for internal use pre-C++20. NFC for external users. Revision 367120 Fix a bug in std::chrono::abs where it would fail when the duration’s period had not been reduced. Revision 364884 Add an internal call __libcpp_is_constant_evaluated, which works like std::is_constant_evaluated, except that it can be called at any language level (back to C++98). For older languages, it just returns false. This gets rid of a lot of ifdefs in the libc++ source code. The current status of libc++ can be found here: C++20 status C++17 status C++14 status (Complete) Libc++ open bugs WG21 As I said above, we shipped a CD out of Cologne. Now we wait for the National Bodies (members of ISO, aka “NBs”) to review the draft and send us comments. When we’ve resolved all of these comments, we will send the revised draft out for balloting. If the NBs approve, then that draft will become C++20. We approved many new features for C++20 in Cologne: P0553 - Bit Operations P0980 - Constexpr string P1004 - Constexpr vector P1065 - Constexpr INVOKE P1135 - The C++20 Synchronization Library P1208 - Source Location P0645 - Text Formatting P1361 - Integration of chrono with text formatting P1754 - Rename concepts to standard_case for C++20, while we still can P1614 - Spaceship integration in the Standard Library P0600 - Stop Tokens and a Joining Thread P0631 - Math Constants We also did not approve many proposed features. Most of these were not approved because we ran out of time, rather than any fault of theirs: P1391 - Range constructors for string_view P1394 - Range constructors for span P0288 - any_invokable P0201 - polymorphic_value P0429 - A Standard flatmap P1222 - A Standard flatset P0533 - constexpr for cmath P0792 - function_ref P0881 - A Proposal to add stacktrace library P1272 - Byte-swapping P0627 - Function to mark unreachable code and many others I still have a bunch of mechanical changes that need to be made before we ship: P1718R0: Mandating the Standard Library: Clause 25 - Algorithms library P1719R0: Mandating the Standard Library: Clause 26 - Numerics library P1720R0: Mandating the Standard Library: Clause 28 - Localization library P1721R0: Mandating the Standard Library: Clause 29 - Input/Output library P1722R0: Mandating the Standard Library: Clause 30 - Regular Expression library P1723R0: Mandating the Standard Library: Clause 31 - Atomics library We polled the NBs before Cologne, and they graciously agreed to have these changes made post-CD. Boost The next Boost release cycle is in process; I am helping Michael Caisse as release manager with this release. We should have a release in the next couple of weeks. Conferences Upcoming talks: CppCon in September in Denver. C++ Russia is at the end of October in St. Petersburg. ACCU Autumn is right after the WG21 meeting in early November. Meeting C++ is in mid-November in Berlin. I will be making the “Fall 2019 C++ European Tour”, going from St. Petersburg to Belfast to Berlin before heading home mid-November.

This month I’ve been working on the following projects: Certify Boost.Beast Certify After quite a bit of work exploring ways to make certificate verification more complete, I’ve concluded that Boost is currently missing a few tools to make that viable. A comprehensive solution requires, at the very least, a functional HTTP client able to handle higher-level semantics like redirects, proxies or compressed bodies. While these are unlikely to happen while performing an OCSP query or downloading a CRL set from Google’s update service, they still need to be handled, otherwise the user will be left in a no better state than when no library is used. At this point, Certify only offers basic verification, but that is still simillar level to what cURL does. Providing a comprehensive solution will require either a infrastructure solution (something like Google’s CRLsets) or a library based one (i.e. build up all the required libraries to be able to perform proper certificate status checks). Boost.Beast I’ve continued the work on expanding split compilation in Beast, by turning some internal function templates, in websocket code, into regular functions. Additionally, I’ve simplified the websocket prng code after proving with some benchmarks that the previous solution made it worse both for the fast case (with TLS enabled) and the slow one. The speed up is marginal, but it made the code much simpler and reduced the size of binaries by small amount (a few K at best). I’ve also worked to cleaning up some of the compilation warnings that I found using the new Azure Piepelines CI in Beast. I also had to deal with an an odd case of miscompilation under MSVC 14.2 (x64 Release), where the use of static_string<7> failed tests with paritally garbage output while static_string<8> succeeded.

There are four main areas where I spend my time. Libc++, where I am the “code owner” WG21, where I am the chair of the Library Working Group (LWG) Boost Speaking at conferences Libc++ The next big milestone for libc++ is the LLVM 9.0 release this summer. We’re working towards that, implementing new features and fixing bugs. The “Branch for release” is currently scheduled for July 18th. As the “code owner” for libc++, I also have to review the contributions of other people to libc++, and evaluate and fix bugs that are reported. That’s a never-ending task; there are new contributions ever day. I created a status page for the LWG issues and papers that are already set up for a vote at the Cologne WG21 meeting. LWG issues resolved this month in libc++ (almost certainly incomplete) LWG2221 No formatted output operator for nullptr LWG3206 year_month_day conversion to sys_days uses not-existing member function LLVM features implemented this month (almost certainly incomplete) P0553 Bit operations P0556 Integral power-of-2 operations P1355 Exposing a narrow contract for ceil2 P0646 Improving the Return Value of Erase-Like Algorithms I LLVM bugs resolved this month (probably incomplete) Bug 41843 std::is_base_of should give correct result for incomplete unions Bug 38638 Wrong constraint for std::optional<T>::operator=(U&&) Bug 30589 std::complex with a custom type does not work because of how std::__promote is defined Bug 42396 Alignment not respected in containers for over-aligned enumeration types Bug 28704 num_get::do_get incorrect digit grouping check Bug 18074 Undefined references when using pointer to member functions Bug 26503 std::quoted doesn’t work with char16_t or char32_t strings. Bug 41714 std::tuple<> is not trivially constructible Bug 36863 basic_string_view(const CharT*, size_type) constructor shouldn’t comment out assert of nullptr and length checks Bug 42166 to_chars can puts leading zeros on numbers Other LLVM bits from this month (certainly incomplete) Revision 364545 Provide hashers for string_view only if they are using the default char_traits. Reported on StackOverflow Reworked to_string to use to_chars. Much faster, and avoids having multiple implementations. This involved reworking to_chars so that it was available back to C++03. I did all of the to_chars refactoring, but not the to_string rework. The current status of libc++ can be found here: C++20 status C++17 status C++14 status (Complete) Libc++ open bugs WG21 The next WG21 meeting is July 15-20 in Cologne, Germany. There were no WG21 meetings in June. We (LWG) held four teleconference this month, reviewing papers in advance of the July meeting, and will have another one next week. I had seven papers in the pre-Cologne mailing: P1718R0: Mandating the Standard Library: Clause 25 - Algorithms library P1719R0: Mandating the Standard Library: Clause 26 - Numerics library P1720R0: Mandating the Standard Library: Clause 28 - Localization library P1721R0: Mandating the Standard Library: Clause 29 - Input/Output library P1722R0: Mandating the Standard Library: Clause 30 - Regular Expression library P1723R0: Mandating the Standard Library: Clause 31 - Atomics library P1724R0: C++ Standard Library Issues to be moved in Cologne The goal of the July meeting is to have a “Committee Draft” (CD) of the proposed C++20 standard that can be sent out for review. Also on my TODO list is to attempt to implement some of the proposals that are coming up for a vote in July (flat_map, text formatting, etc). Boost The next Boost release cycle is in process; I am helping Michael Caisse as release manager with this release. Conferences Upcoming talks: C++ Russia is at the end of October in St. Petersburg. Meeting C++ is in mid-November in Berlin. I have submitted a talk for CppCon in September, but I will not hear back about this for a month or two. I submitted a talk for ACCU Autumn, which is in Belfast right after the WG21 meeting, but I haven’t heard back about that yet. In any case, I will be attending this conference, since it’s in the same hotel as the WG21 meeting, and starts two days after the WG21 meeting, and concludes right before Meeting C++.

This month I’ve been working on the following projects: Certify Boost.Beast Boost.Build Certify This month, I’ve worked on expanding the documentation of Certify, especially the example and introduction parts. When looking through the documentation for Boost.Build I found out it’s possible to import snippets from *.cpp files into the documentation, which will allow me to make sure that snippets in the documentation compile and are tested. I’ve also attempted cleaning up the Certify build script to use the OpenSSL module in b2, but I ran into issues, so I’ll have get back to this one in the future. Don’t forget to star the repository: https://github.com/djarek/certify! Boost.Beast I’ve been able to complete the port of the Beast CI to Azure Pipelines and expand the test matrix beyond what was tested in the existing CI infrastructure. Thanks to the expanded concurrent job limit, a full run on AzP takes less time than a full Travis and Appveyor build, especially when wait times are taken into accout. One of the matrix items I added were tests for header-only no-deprecated builds, which turned out to be broken. Untested code has a nasty tendency to rot. I’ve also been able to identify some function templates in http::basic_fields which could be turned into regular functions. One of them, was instantiated 4 times because they were passed a predicate which was a lambda expression. These two changes turned out to be fairly significant, because they allowed shaving off at least 10 KiB of binary size per instantiation (amd64, -O3). Boost.Build When working on the Azure Pipelines CI for Beast I noticed that b2 doesn’t support the leak sanitizer, so I decided to add it. It’s available via the leak-sanitizer=on feature.

There are four main areas where I spend my time. Libc++, where I am the “code owner” WG21, where I am the chair of the Library Working Group (LWG) Boost Speaking at conferences Libc++ The next big milestone for libc++ is the LLVM 9.0 release this summer. We’re working towards that, implementing new features and fixing bugs. As the “code owner” for libc++, I also have to review the contributions of other people to libc++, and evaluate and fix bugs that are reported. That’s a never-ending task; there are new contributions ever day. This month was spent concentrating on code reviews and bug reports; so I implemented very little “new code”. There was a lot of “infrastructure work” done on libc++ this month; a large cleanup of the test suite (still in progress), a bunch of work on debug mode for the library (also still in progress) LWG issues resolved this month in libc++ 2960 sub_match::swap only swaps the base class LLVM features implemented this month (certainly incomplete) Improved the behavior of the compiler intrinsic __is_base_of. Clang no longer generates an error when you ask about inheritance relationships with unions, even if the non-union class is incomplete. This intrinsic is used by libc++ to implement std::is_base_of. Fixed a few regex bugs, and improved the regex tests in C++03. LLVM bugs resolved this month (probably incomplete) Bug 42037 C++2a std::midpoint`’s “Constraints” are not implemented Bug 41876 std::hash should not accept std::basic_strings with custom character traits The current status of libc++ can be found here: C++20 status C++17 status C++14 status (Complete) Libc++ open bugs WG21 There were no WG21 meetings in April. However, LWG held one teleconference this month, reviewing papers in advance of the July meeting. We’ll have more teleconferences in June. I am working on more “cleanup” papers similar to P1458 - Mandating the Standard Library: Clause 16 - Language support library, and my P0805 - Comparing Containers needs an update. The goal of the July meeting is to have a “Committee Draft” (CD) of the proposed C++20 standard that can be sent out for review. Also on my TODO list is to attempt to implement some of the proposals that are coming up for a vote in July (flat_map, text formatting, etc). Boost It’s been a quiet month for boost (except for C++ Now, the conference formerly known as BoostCon). There are a couple of good trip reports for C++Now: Matthew Butler JeanHeyd Meneide The next Boost release cycle is starting soon; with the deadline for new libraries coming up later this month. I’m hoping to mentor a new release manager with this release. Conferences Another travel month. I spent a bunch of time away from home, but only one conference: At C++ Now in Aspen, CO, I presented “The View from a C++ Standard Library Implementor”, which was voted the runner-up for “Most Engaging” talk. I have submitted a talk for CppCon in September, but I will not hear back about this for a month or two. I have submitted talks for C++ Russia and Meeting C++, which are both very close (timewise) to the Belfast WG21 meeting, but I haven’t heard back yet. I am looking forward to being at home for the entire month of June.

This month I’ve been working on the following projects: Certify Boost.Beast Boost.Build BeastLounge Certify Certify did not have any platform-independent means of caching certificate status (i.e. revoked, valid, unknown), so I implemented one. For now it has to be manually filled, but I’ll add a way to import a static blacklist (somewhat similar to the builtin blacklist in Chrome) and query the status of a certificate. Unfortunately there is no way to handle OCSP stapling within the verification callback invoked by OpenSSL which is quite detrimental to usability. Additionally, OpenSSL doesn’t have a way of starting and waiting for an asynchronous operation within callbacks (without blocking). Don’t forget to star the repository: https://github.com/djarek/certify! Boost.Beast When working on making sure Beast is std::launder-correct, I ran into a number of previously undiagnosed bugs in Beast. All of them have been fixed in v254. I was quite confused why these issues weren’t found by CI previously. I’ve been able to track it down to old toolchain versions in Travis. Additionally, the test matrix lacks a few fairly important variants. Considering the fact that Trusty is no longer supported and the switch to Xenial is inevitable, I’ve decided to port over the CI to Azure Pipelines, because it offers better concurrency which allows the Beast CI to afford a larger test matrix. In the process I’ve also decided to use as many default b2 options as possible, to make future changes to the CI easier. There’s still an issue with Valgrind in Xenial to be resolved (doesn’t support the RDRAND instruction). Boost.Build While working on the AzP CI for Beast, I found out that the coverage feature in b2 doesn’t actually set build flags. coverage=all will now properly cause tests to produce gcno and gcda files for consumption by the lcov tool. BeastLounge When experimenting with the BeastLounge application running on Heroku I found out that Heroku’s router has a builtin 55s timeout which dropped websocket connections. I solved the issue by making the websocket ping timeouts configurable.

There are four main areas where I spend my time. Libc++, where I am the “code owner” WG21, where I am the chair of the Library Working Group (LWG) Boost Speaking at conferences Libc++ The next big milestone for libc++ is the LLVM 9.0 release this summer. We’re working towards that, implementing new features and fixing bugs. As the “code owner” for libc++, I also have to review the contributions of other people to libc++, and evaluate and fix bugs that are reported. That’s a never-ending task; there are new contributions ever day. LWG papers implemented this month. P0811 Add std::midpoint and std::lerp for C++20 LWG issues resolved this month 2960 nonesuch is insufficiently useless 2977 unordered_meow::merge() has incorrect Throws: clause 2164 What are the semantics of vector.emplace(vector.begin(), vector.back())? LLVM features implemented this month (certainly incomplete) Fixed the implementations of list::remove_if and list::unique to deal with values or predicates that are elements in the list. Same for forward_list. We did this for remove already, but now we do it for the other operations as well. Added a bunch of new tests for things that we were missing ** list::sort and forward_list::sort are required to be stable. ** You can’t use match_results until you’ve done a regex search. Our tests did this in several places; now we have assertions to prevent that. ` LLVM bugs resolved this month (probably incomplete) Bug 41323 Race condition in steady_clock::now for _LIBCPP_WIN32API Bug 41130 operator/ of std::chrono::duration and custom type. Bug 41577 test/std/utilities/optional/optional.object/optional.object.ctor/move.fail.cpp has wrong assumption. I spent a fair amount of time on Bug 39696 “Workaround “error: ‘(9.223372036854775807e+18 / 1.0e+9)’ is not a constant expression”; which turned out to be a GCC bug on PowerPC machines. Also, there was a series of general cleanups in the libc++ tests to improve portability and readability. I added a bunch of updates for debug-mode, and there were several places where we assumed that string::compare returned -1/0/1 instead of what was specified, which is \<0/0/\>0. Also, I added tests for std::any_cast and array types. The current status of libc++ can be found here: C++20 status C++17 status C++14 status (Complete) Libc++ open bugs WG21 There were no WG21 meetings in April. However, LWG held three teleconferences this month, reviewing papers in advance of the July meeting. We’ll have more teleconferences in May. I am working on more “cleanup” papers similar to P1458 - Mandating the Standard Library: Clause 16 - Language support library, and my P0805 - Comparing Containers needs an update. The goal of the July meeting is to have a “Committee Draft” (CD) of the proposed C++20 standard that can be sent out for review. Also on my TODO list is to attempt to implement some of the proposals that are coming up for a vote in July (flat_map, text formatting, etc). Boost We released Boost 1.70 on the 12th of April. Once again, I was the release manager, which involved a bunch of “process management”; things like assembling the release candidates, packaging up release notes, deciding which problems that came up would be fixed (and which ones would not), and updating the web site (and so on, and so on). Conferences This was a big travel month. I gave two presentations: At the LLVM European Developer’s conference in Brussels, I gave a 30 minute overview of the changes that were coming to the standard library for C++20. At ACCU in Bristol, England, I gave a talk titled “Navigating the development and evolution of a library” In May, I will be speaking at: CppNow, May 5-10 in Aspen, CO I have submitted a talk for CppCon in September, but I will not hear back about this for a month or two.

This month I’ve been working on the following projects: Certify Boost.Beast Boost.Build BeastLounge Certify Certify now properly verifies the hostname of a TLS server according to RFC 2818 or TLS-DANE if available. Additionally, initial support for CRLSets has been merged, although it’s still missing integration into the verification code. I’ve also invested a fair bit of time into researching what other open source libraries do to perform certificate status checking. I’ve looked into BoringSSL, mbedTLS, Botan and even the Go standard library. It’s interesting that no library has a default way of performing the status check of a certificate and it’s left up to the user. The Windows implementation of the certificate store in Certify will now properly use the entire chain passed by the peer, which resolves certificate failures in less common cases. Don’t forget to star the repository: https://github.com/djarek/certify! Boost.Beast Most of the work this month involved making Beast compile faster and use less memory by expanding the code that can use split compilation and reducing redundant dependencies in a few places. Boost.Build I’ve worked on implementing 2 improvements that make it less painful to work with b2: support for finding OpenSSL support for sanitizers in gcc and clang Both are currently still in review. BeastLounge The project lacked functioning CI so I implemented one. Since the project was previously only compiled on MSVC, this proved to be quite challenging, because MSVC accepts code that is not valid C++11. I’ve also created a deplyoment docker image, which allows running the application in popular cloud environments, like Heroku. A development version of the app is available at https://beast-lounge.herokuapp.com/.

There are four main areas where I spend my time. Libc++, where I am the “code owner” WG21, where I am the chair of the Library Working Group (LWG) Boost Speaking at conferences This month, I spent far more time reviewing other people’s code and preparing talks for conferences than the previous few months. The Boost release process consumed a fair chunk of time as well. Libc++ The big news is: we released LLVM 8 this month! (March 20th). You can get the sources and pre-built binaries from the LLVM download page, or wait for your system vendor to provide you with an update. As the “code owner” for libc++, I also have to review the contributions of other people to libc++, and evaluate and fix bugs that are reported. That’s a never-ending task; there are new contributions ever day. LWG papers implemented this month. P0811 std::midpoint for integral and pointer types. This turned out to be quite involved, and spawned a clang bug report. On the plus side, now I have a topic for a talk for CppCon this fall. Still to do, std::midpoint for floating point types. This is done, but it needs better tests. LWG issues implemented this month I didn’t actually commit any LWG issue fixes this month. I worked with others on several bug fixes that landed, but not under my name. LLVM features implemented this month (certainly incomplete) Add noexcept to operator[] for array and deque Mark vector::operator[] and front/back as noexcept Mark front() and back() as noexcept for array/deque/string/string_view Make to_chars/from_chars work back to C++11. This lets us use them in to_string. LLVM bugs resolved this month (probably incomplete) Bug 35967 <regex> syntax_option_type is not a proper bitmask No bug # Fix a minor bug with std::next and prev not handling negative numbers. No bug # Cleanup of requirements for optional - we no longer allow optional<const in_place_t> Bug 41130 operator/ of std::chrono::duration and custom type. Also, there was a series of general cleanups in the libc++ tests to improve portability and readability. Eric and I (mostly Eric) revamped the debug-mode support, and there will be more activity there in the future. Also, we’re moving towards using more of the ASSERT_XXXX macros for readability, and I revamped about 30 of the tests to use them. Only several thousand to go! The current status of libc++ can be found here: C++20 status C++17 status C++14 status (Complete) Libc++ open bugs WG21 The “winter” WG21 meeting was held in Kona, HI on February 18-24. This was the last meeting for new features for C++20, and as such, it was both contentious and very busy. Between now and the next meeting (July), LWG will be working on reviewing papers and issues to be adopted in July. We have had three teleconferences since Kona, and a fourth is scheduled for mid-April. I am working on more “cleanup” papers similar to P1458 - Mandating the Standard Library: Clause 16 - Language support library, and my P0805 - Comparing Containers needs an update. The goal of the July meeting is to have a “Committee Draft” (CD) of the proposed C++20 standard that can be sent out for review. Boost It’s time for another Boost release (1.70), and I am acting as the release manager again. The release calendar is available (as always) on the Boost website. The cut-off for contributions for the release is 3-April, with a release candidate to follow close behind, and the actual release to happen on the 10th. Once the release is over, I’ll be putting some serious time into Boost.Algorithm; there are a bunch of C++17/20 algorithms that can be added to the library (among other things). Conferences I had submitted talk proposals to three conferences, and all three were accepted. I will be speaking at: LLVM European Developer’s Conference, April 8-9 in Brussels ACCU, April 10-13 in Bristol CppNow, May 5-10 in Aspen, CO

Certify - X509 certificate validation I always knew that validating a certificate chain presented by a peer is not an easy procedure, but my recent work in Certify to port over the procedure from Chromium has only proven that I underestimated the complexity of it. Certificate revocation seems to be a particularly hard issue, with 2 main categories of solutions - offline and online validation. Online validation - OCSP OCSP is a protocol designed to allow checking the revocation status of a certificate by sending a request over a subset of HTTP/1.1. At first glance, it seems it solves the status checking problem on its own. However, OCSP has problems, inherent to online checking. First of all, the validation server might not be currently available - so a lack of response is most definitely not a state in which a chain can be trusted. Secondly, the check may be slow, after all, it requires connecting to a separate service. Additionally, the native Windows API for certificate verification does the status check synchronously, which means potentially blocking a user’s thread that typically services asynchronous operations. There is a feature that alleviates most of these issues, at least from the point of view of a TLS client, OCSP stapling. Sadly, it’s not very widespread and actually few large services support it, due to the fact that it increases bandwidth requirements. Certify will, at some point support both OCSP status checks on the client side and support for OCSP stapling. The problem here is that OCSP requires a fairly functional HTTP client and ASN.1 parsing. A lot of this functionality is already present in OpenSSL, however, integrating it with ASIO and Beast may be tricky. Offline validation - CRLs and Google CRLSets The traditional method of checking the status of a certificate involves looking up revocation lists installed in the OS’s store, or downloaded by the application from the CA. Unfortunately CRLs have issues - an example would be an incident from a few years ago when CloudFlare performed a mass revocation which blew up the size of the CRLs by a few orders of magnitude, resulting in a requirement to download multiple megabytes of data, turning CAs into a major performance bottleneck. Google came up with a different mechanism, called CRLSets, which involves a periodic download of a revocation list which is created by Google’s crawler querying certificate status over OCSP. This verification method is fairly attractive for applications that run on systems that already have Google products, since this database is shared, which is why I’ve chosen to provide an opt-in implementation in Certify. For now, updating the database will be out of scope, because that requires a few utilties that are missing from Boost at this time (XML, JSON and an HTTP Client). Don’t forget to star the repository: https://github.com/djarek/certify!

The Alliance is a Gold sponsor for C++Now 2019. This conference is a gathering of C++ experts and enthusiasts from around the world in beautiful Aspen, Colorado from May 5, 2019 - May 10, 2019.

Monthly update (or, what Marshall did in January and February) There are four main areas where I spend my time. Libc++, where I am the “code owner” WG21, where I am the chair of the Library Working Group (LWG) Boost Speaking at conferences Libc++ The LLVM “branch for release” occurred in January, and there was a bit of a rush to get things into the LLVM 8 release. Now that is over, and we’re just watching the test results, seeing if anyone finds any problems with the release. I don’t anticipate any, but you never know. As the “code owner” for libc++, I also have to review the contributions of other people to libc++, and evaluate and fix bugs that are reported. That’s a never-ending task; there are new contributions ever day. After the branch, I started working on new features for the LLVM 9 release (for this summer). More calendaring stuff, new C++20 features, and some C++17 features that haven’t been done yet. LWG papers implemented in Jan/Feb P0355: Extending to Calendars and Time Zones. You may remember this from last month's update; this is a huge paper, and I am landing it in stages. P1024: tuple-like interface to span P1227: Signed ssize() functions P1357: Traits for [Un]bounded Arrays LWG issues implemented in Jan/Feb (certainly incomplete) LWG3101: span’s Container constructors need another constraint LWG3144: span does not have a const_pointer typedef Enabled a memcpy optimization for const vectors that was surprisingly missing LLVM bugs resolved in Jan/Feb (probably incomplete) Bug 28412 std::vector incorrectly requires CopyConstructible, Destructible and other concepts Bug 39183 tuple comparison operators return true for tuples of different sizes Bug 24411 libFuzzer outputs that crash libc++’s regex engine Bug 34330 error: use of undeclared identifier ‘isascii’ while compiling strstream.cpp Bug 38606 no_sanitize(“unsigned-integer-overflow”) annotation for decremented size_type in __hash_table Bug 40533 std::minmax_element is 3 times slower than hand written loop Bug 18584 SD-6 Feature Test Recommendations Bug 40566 Libc++ is not Implicit Integer Truncation Sanitizer clean Bug 21715 128-bit integers printing not supported in stl implementation Bug 38844 __cpp_lib_make_unique not defined in <memory> Bug 40495 is_invokable_v<void> does not compile Bug 40270 std::basic_stringstream is not working with std::byte Bug 39871 std::tuple_size should be a struct Bug 38052 std::fstream still good after closing and updating content Also, there was a series of general cleanups in the libc++ tests to improve portability. The current status of libc++ can be found here: C++20 status C++17 status C++14 status (Complete) Libc++ open bugs WG21 The “winter” WG21 meeting was held in Kona, HI on February 18-24. This was the last meeting for new features for C++20, and as such, it was both contentious and very busy. The Modules TS and the Coroutines TS were both adopted for C++20, along with a slew of language features. Here are some trip reports: Herb Sutter Bryce Adelstein Lelbach Guy Davidson My part in this was (as always) to chair the Library Working Group (LWG), the group responsible for the description of the library features in the standard (~1000 pages). We adopted several new features for C++20: P0339R6 polymorphic_allocator<> as a vocabulary type P0340R3 Making std::underlying_type SFINAE-friendly P0738R2 I Stream, You Stream, We All Stream for istream_iterator P0811R3 Well-behaved interpolation for numbers and pointers P0920R2 Precalculated hash values in lookup P1001R2 Target Vectorization Policies from Parallelism V2 TS to C++20 P1024R3 Usability Enhancements for std::span P1164R1 Make create_directory() Intuitive P1227R2 Signed ssize() functions, unsigned size() functions P1252R2 Ranges Design Cleanup P1357R1 Traits for [Un]bounded Arrays I wrote five substantive papers for the Kona meeting, all were adopted. Five of them were very similar, all about improving the wording in the standard, rather than proposing new features. P1458 Mandating the Standard Library: Clause 16 - Language support library P1459 Mandating the Standard Library: Clause 18 - Diagnostics library P1462 Mandating the Standard Library: Clause 20 - Strings library P1463 Mandating the Standard Library: Clause 21 - Containers library P1464 Mandating the Standard Library: Clause 22 - Iterators library I was also the nominal author of P1457 “C++ Standard Library Issues to be moved in Kona”, but that was just a list of issues whose resolutions we adopted. Between now and the next meeting (July), LWG will be working on reviewing papers and issues to be adopted in July. I’m planning regular teleconferences (in fact, we had the first one on 1-March). The goal of the July meeting is to have a “Committee Draft” (CD) of the proposed C++20 standard that can be sent out for review. Boost It’s been a quiet couple of months for Boost, since we’re between releases, and I have been busy with libc++ and WG21 activities. There have been a few bugs to chase down, and the dealing with change requests for the libraries whose maintainers have “moved on” takes some time. However, it’s time for another Boost release (1.70), and I will be acting as the release manager again. The release calendar is available (as always) on the Boost website. The beta release is schedule for March 13th, and the final release for 10-April. Conferences I had submitted talk proposals to three conferences, and all three were accepted. Hence, I will be speaking at: LLVM European Developer’s Conference, April 8-9 in Brussels ACCU, April 10-13 in Bristol CppNow, May 5-10 in Aspen, CO

The Alliance engages Adler & Colvin to complete IRS Form 1023, Application for Recognition of Exemption Under Section 501(c)(3) of the Internal Revenue Code. Completing this form can be a daunting task because of the legal and tax technicalities you’ll need to understand. Adler & Colvin is a group of seasoned attorneys based in San Francisco, deeply committed to serving the legal needs of the nonprofit sector. The firm brings an unrivaled depth of expertise and passion to its representation of tax-exempt organizations and individual philanthropists.

Monthly update (or, what Marshall did in December) There are three main areas where I spend my time. Boost Libc++ WG21, where I am the chair of the Library Working Group (LWG) Boost: December was a big month for boost, and much of the first part of the month was taken up with the release process. I was the release manager for the 1.69.0 release, which went live on 12-December. The final release process was fairly straighforward, with only one release candidate being made/tested - as opposed to the beta, which took three. In any case, we had a successful release, and the I (and other boost developers) are now happily working on features/bug fixes for the 1.70 release - which will occur in March. Libc++: After the WG21 meeting in November, there was a bunch of new functionality to be added to libc++. The list of new features (and their status) can be seen on the libc++ website. My major contributions of new features in December were Consistent Container Erasure, char8_t: A type for UTF-8 characters and strings, and Should Span be Regular?, and a big chunk of [Extending to Calendars and Time Zones](https://wg21.link/P0355R7). This is all pointing towards the January 16th “branch for release”, and for the scheduled March release of LLVM 8.0. As the “code owner” for libc++, I also have to review the contributions of other people to libc++, and evaluate and fix bugs that are reported. That’s a never ending task; there are new contributions ever day. WG21 Being between meetings (November -> February) there was not any special WG21 work to be done in December. There’s an ongoing stream of bug reports, discussion, paper reviews that get done between meetings, and there is a series of papers that I need to finish for the pre-Meeting mailing deadline on 21-January. I have 1 1/2 done, and need to do 3-4 more.

WG21 San Diego Meeting Last week was the fall 2018 WG21 standard committee meeting. It was held in San Diego, which is my hometown. The fact that I helped organize it (while I was working at Qualcomm) had absolutely no affect on the location, I assure you. ;-) This was the largest WG21 meeting ever, with 180 attendees. The last meeting (in Rapperswil, Switzerland) had about 150 attendees, and that was the largest one until now. There were more than 270 papers in the pre-meeting mailing; meaning that people were spending weeks reading papers to prepare for the meeting. Herb Sutter (the convener) has been telling everyone that new papers received after the San Diego meeting were out of scope for C++20, and apparently people took him at his word. This was my first meeting representing the C++ Alliance (though hardly my first overall). The Alliance was well represented, with Rene, Glen, Vinnie, Jon and myself attending. For information about how WG21 is structured, please see isocpp.org. I spent all of my time in LWG, since that’s the group that I chair, and the one that has the most influence over libc++, the library that I work on. The big news from a library POV was that we voted to merge an updated paper based on the Ranges TS into the draft standard; which means that (barring catastrophe) that it will be part of C++20. This was a huge paper, weighing in at 220+ pages. We spent several days in LWG reviewing this (and a bunch of time at previous meetings as well). We also moved a bunch (around 25) of smaller papers; too many to list here. Detailed trip reports can be found around the web: Herb Sutter Reddit The next WG21 meeting is in Kona, HI February 18-23rd.

Initial work on Certify complete It’s been mentioned in my initial blog post that I’d be working on a TLS certificate store abstraction library, with the intent of submitting it for formal review for Boost, at some point in the (hopefully near) future. The initial setup phase (things that every Software Engineer hates) is more or less complete. CI setup was a bit tricky - getting OpenSSL to run with the boost build system on both Windows and Linux (and in the future MacOS) has provided a lot of “fun” thanks to the inherent weirdness of OpenSSL. The test harness currently consists of two test runners that loads certificates from a database (big name for a folder structure stored in git) that has the certificate chains divided into two groups. Chains that will fail due to various reasons (e.g. self-signed certificates, wrong domain name) and ones that will pass (when using a valid certificate store). I’m still working on checking whether the failure was for the expected reason. All the verification is done offline (i.e. no communication with external servers is performed, only chain verification). At this point it looks like I should consider, whether the current design of the verification code is a good approach. Using the verification callback from OpenSSL and asio::ssl is quite an easy way of integrating the platform-specific certificate store API it causes issues with error propagation (transporting a platform-specific error through OpenSSL) and may be fairly slow, because it requires certificates to be reencdoded into the DER format so that they can be fed into the platform-specific API. An alternative to this approach would be load the entire root certificate store, along with CRLs and OCSP configuration into an OpenSSL context. This is potentially a little bit harder to get right but may offer better performance (no reencoding required when veryfing certificate chains) and eliminates the issues related to error handling. Further investigation, as to which approach is better, is required. Don’t forget to star the repository: https://github.com/djarek/certify!

The Alliance is a Gold sponsor for CppCon 2018. This conference is the annual, week-long face-to-face gathering for the entire C++ community. The conference is organized by the C++ community for the community. Attendees enjoy inspirational talks and a friendly atmosphere designed to help individuals learn from each other, meet interesting people, and generally have a stimulating experience.

Damian Jarek joins the Alliance as Staff Engineer. Previously he worked on a number of embedded networking projects for a few major clients. As a Staff Engineer he’ll be working on an open-source companion library for Boost.Beast and Boost.Asio, which will abstract away the platform-specific details of acessing system proxy settings and performing TLS verification of a peer certificate chain using the operating system’s key store.

Marshall Clow joins the Alliance as a Staff Engineer. Previously, he worked at Qualcomm for many years. Most of his time is spent working on libc++, the C++ standard library implementation for LLVM. He is also a member of the C++ standards committee, currently serving as the chair of LWG, the library working group. Marshall has been contributing to the Boost libraries since 2001, and is the author of the Boost.Algorithm library. Furthermore he maintains several other boost libraries, and moderates some of the boost mailing lists. Finally, Marshall has graciously taken on the role of release manager for several Boost versions.

The Alliance engages The Law Firm for Non-Profits for legal representation and services. They are passionate about supporting, advocating for and partnering with non-profits and the people behind them. For more than three decades, those looking for assistance with non-profit law throughout the United States and around the world have relied on the attorneys of The Law Firm for Non-Profits for superior legal and business guidance.

The Alliance is member of the International Committee for Information Technology Standards. INCITS is the central U.S. forum dedicated to creating technology standards for the next generation of innovation. INCITS members combine their expertise to create the building blocks for globally transformative technologies. From cloud computing to communications, from transportation to health care technologies, INCITS is the place where innovation begins. Membership in INCITS allows voting in official WG21 meetings.

The Alliance is a Gold sponsor for C++Now 2018. This conference is a gathering of C++ experts and enthusiasts from around the world in beautiful Aspen, Colorado.

A new corporate logo is adopted from the conclusion of a contest on Designhill:

Vinnie Falco joins the Alliance board of directors as president.

René Rivera joins the Alliance board of directors as secretary.

Jon Kalb joins the Alliance board of directors as treasurer.

Glen Joseph Fernandes, a Boost C++ library author, contributor, maintainer, joins as a technical advisor.

The board of directors establishes the Technical Committee, whose job is to inform the CEO and board on all technical matters such as code review, resume review, the quality of papers, and other ongoing work.

The Alliance is now the owner and administrator of the Cpplang Slack Workspace. This workspace is the premiere and most popular community of C++ enthusiasts and professionals from around the globe.

The Alliance engages InCorp Services, Inc. as the registered agent. InCorp provides National Registered Agent services in all 50 states and Washington, D.C.

The Alliance engages Foundation Group, a non-profit formation and compliance services company. Foundation Group delivers a comprehensive 501(c)(3) registration service with a 100% IRS approval rate.

Jens Weller, the organizer and founder of Meeting C++, joins the Alliance as an advisor.

Louis Tatta joins the Alliance in the role of Chief Executive Officer, to oversee and administer the day to day operations of the company and carry out the mission.

The C++ Alliance, Inc. officially incorporates as a California 501(c)(3) non-profit organization. The company is administered entirely as a virtual entity with no physical office.

Beast, an HTTP and WebSocket protocol library written in C++11, becomes part of the Boost library collection.