Moving from Fost 4 to Fost 5

The new version of Fost is going to have a large number of breaking changes that will affect pretty much every aspect of the libraries' use. The reason for this is quite simple, C++11 is really a new language when compared to C++03. Many of these changes will be brought about due to simple changes brought about by the promotion of many Boost libraries into the standard library.

Targets and approach

The plan is to support C++14 with whatever compilers we can use to do this. The current latest version of Ubuntu at least has the features we need to make a start here. I hope that Microsoft Visual C++ 2013 also has enough support to at least get started. We still aren't in a position to support Mac OS X as I don't have access to the platform in a manner suitable for testing — it isn't clear to me that this is even possible without a huge investment due to inherent limitations of OS X virtualisation.

There's likely to be a problem with compilers on the older Ubuntu platforms that's likely to necessitate building both a compiler and Boost. Hopefully Docker can help make this somewhat simpler.

Initially we'll be wanting to support Ubuntu Precise (12.04) and later, and Windows with Microsoft Visual C++ 2013. We'll also support Android with NDK 10c and later.

For Python we intend to move to Python 3 and drop support for 2.

The change from Fost.3 to 4 was done by a complete rebuild of all of the files from the ground up. That isn't what will happen this time. Instead we'll start to build Fost 5 with the newer compile flags and then start to make the breaking changes that we want. These breaking changes will continue for the first releases of Fost 5 — this appears to be unavoidable given the resources we have to do this work with.

Change roadmap

There's a number of changes that are obviously needed even before starting work on anything: Firstly, there's a number of Boost libraries that we can now replace with standard libraries:

Smart pointers
Threads
Many uses of type traits, lambdas and functors.
Regex
Filesystem (subject to compiler support)

It's clear that Fost 5 will continue to require a large part of Boost.

There's also a list of changes we want to make to the libraries as well:

The argument parsing implementation dates from 1995 and isn't all that great. It'd make more sense to either drop it entirely in favour of a more modern implementation, or at least build something that is more POSIX like. Initialiser lists should make configuring the options in code far simpler.
There are many places were we'd want to use the JSON implementation, but have wanted to augment the types that can be stored in the structure. This can be done by having a base template implementation that can then be extended by additional user types. Variadic templates will make this far simpler.
Much of the thread implementation can be replaced with standard items, hopefully including the futures. There's still likely to be uses for the worker and work pools though. The message passing here will be substantially easier to use with lambdas. The current counter can be dropped in favour of atomics, but it's likely that we'll still want something that can aggregate counts across multiple threads far more efficiently.
Boost still uses the oldest version of Spirit for parsing, and has a number of number of wrappers to get around threading problems (which probably aren't needed). It would be best to upgrade this to the current version.

Question marks

Boost build is a pain, and hard for other people to work with. There's a lot of things I'd like to be able to get out of the build process, but customising Boost build is always a constant frustration. It isn't at all clear that any other build system would be a significant improvement. The only way to really know whether something else is going to be better is to try it out.

SCons looks good in that it's building Python, already a dependency in the build process. But for large projects it's slow, and we use this to build large projects (sometimes hundreds of thousands of build targets). CMake also looks interesting, but extending it will be a nightmare and it's hard to know if it has the features that Fost needs or not, let alone features for things we'd like to do.

It may also be time to look again at testing. C++11's lambda syntax gives a lot of extra flexibility there. It ought to be possible to produce something much closer to a Jasmine style of tests now rather than the current macro based system.

A bigger question hangs over Boost ASIO. Fost 4 doesn't take advantage of the asynchronous features, preferring instead to use threads as building blocks rather than callbacks. This means a certain amount of fighting the API so as to get time outs and blocking working well. What's worse though is the use of OpenSSL — but it isn't at clear what a better alternative would look like. Maybe LibreSSL will become usable across our target platforms in time.

Pages