5

With C++17 now published, even more of Boost's libraries are now covered by the standard library: optional, variant, any, ASIO (in the Networking TS), coroutines (in a TS) and more. This, in addition to the gobs and gobs of Boost stuff already in the standard, see this answer. I realize that some of the standardized versions have slightly different design space choices than Boost's, but essentially it's the same.

Given this fact, are there or have there been plans to release an alternative version (or just - a new mainline version) of Boost which:

  • Foregos most or all of these features as Boost libraries
  • Lets the rest of the Boost code rely on their availability in the standard library
  • Lets the Boost code rely on the language being at least C++17, to make life easier and the code more scrutable to developers

?

If not - is this because of the importance of the Boost design choices? Too much hassle? Fear of "project bifurcation"?

Note: This is an informative question, so please don't provide your opinion or whether this would be a good idea or not.

einpoklum
  • 118,144
  • 57
  • 340
  • 684
  • 1
    You could ask on Boost mailing lists. Or ask Dave Abrahams. – Cheers and hth. - Alf Feb 10 '18 at 19:05
  • 3
    I expect that Boost will be supporting older C++ compilers for quite some time. So I expect the parts of Boost that are redundant under C++17 will still be in the Boost distribution for the foreseeable future (many years). – Eljay Feb 10 '18 at 21:19
  • @Eljay: Ok, but - there could be two branches of Boost - a legacy targeting older systems, and a mainline. Or - do you know that there's a decision to avoid that? – einpoklum Feb 10 '18 at 21:23
  • I work with some of the people involved with Boost, and we use Boost extensively on our product. As it so happens, this month we're C++14, but we expect to flip the compilers to C++17 next month... so your question is timely. I can ask them on Monday. – Eljay Feb 10 '18 at 21:28
  • @dimm: Ok ok. Nitpick. – einpoklum Feb 10 '18 at 21:56
  • @einpoklum Boost's implementations of those libraries are more stable than implementations provided with most standard libraries. Looking at C++11/14, it usually takes up to 5 years for implementations to become somewhat decent. And some remain worse forever. –  Feb 10 '18 at 22:01
  • @Ivan: Provided the implementations comply with the standard, I'm not sure I understand what you mean by being "more stable". Also, in a year, it will be 5 years since C++14... – einpoklum Feb 10 '18 at 22:07
  • @einpoklum I mean they have tons of bugs. Take `std::error_code` for example. On Linux `std::error_code::message` is non-thread safe, although it should be. MSVC implementations `operator==` is non-conformant, error message encoding is broken and message for system category contains redundant "\r\n" at the end. It is also not able to properly match WinAPI error codes. Boost.System is not perfect too, but is _much_ better. There are issues with default narrow encoding in `std::filesytem` on Windows. Boost at least tried to address this. –  Feb 10 '18 at 22:11
  • @Ivan: Oh, that's terrible to hear. I was actually assuming the Boost implementations get copied and adapted, so even if there are bugs here and there, you don't have significant flaws of that kind since the Boost implementors already thought about them. Also, no fair mentioning MSVC... – einpoklum Feb 10 '18 at 22:26
  • @einpoklum Well, if you want support Windows, MSVC is something you might want to use, but even with MinGW some things will be the same - `std::filesystem` is forever broken on Windows no matter what compiler you are using (might work in theory, in practice too easy to misuse and construct path from non-unicode narrow encoding). Sad state of `std::error_code` means everything that relies on it is broken too (`std::filesystem`, future `std::net` etc). –  Feb 10 '18 at 22:29
  • @Ivan: 1. I think you might make your comments into an answer. Can you link to someplace discussing these issues in more depth? Specifically about the issues with `std::error_code`? – einpoklum Feb 10 '18 at 22:31
  • @einpoklum • my coworkers involved with the Boost effort are not aware of any efforts or initiatives to produce a "streamlined" Boost deliverable for the latest or more recent C++ standards. But they added a disclaimer that they are not necessarily aware of all the on-going activities within the Boost community. – Eljay Feb 22 '18 at 14:29

1 Answers1

3

Boost has better implementation than many currently existing implementations of standard C++ library.

Note that:

  • Some issues might be fixed in the latest versions of compilers, I didn't recheck everything before writing this post.
  • Boost is quite conservative and support many old compilers. Even if the latest compiler has everything fixed, older version still have to work.
  • With regards to Unicode, I assume C++ programs will try to follow UTF-8 Everywhere.

Boost.Filesystem vs <filesystem>

Windows has no support for Unicode in both C/C++ runtimes e.g. you cannot switch standard library to Unicode-aware narrow character set (UTF-8). As the result std::filesystem::path always assumes non-unicode encoding when used with char sequences. There is std::filesystem::u8path for this, but writing std::filesystem::path p = some_char_sequence imo is way too easy. Any codebase that uses std::filesystem and supports Windows will have to battle this constantly.

Boost.Filesystem allowed user to specify locale to be used for path objects. Boost.Locale could be used to create UTF-8 locale on Windows, eliminating this issue. Std.filesystem does not allow you to do this.

Boost.System vs <system_error>

On Linux with glibc:

  • std::error_category::message is not thread safe, although it should be. Boost.System at least tries to provide thread-safe implementation for every platform.
  • System category is not able to test for equivalency with standard error conditions.

On Windows (MSVC) it is broken in multiple places:

  • Error messages returned by std::system_category have annoying "\r\n" at the end, which does not happen anywhere else. Boost.System explicitly trims those.
  • Comparing addresses of std::error_category does not work for generic and system categories if used cross-dll. Boost.System never had this issue.
  • Error message is returned using current user enconding (never UTF-8). Technically this is allowed since standard does not specify encoding used here, but it doesn't help anyone. Although Boost.System did the same (should not be mentioned here?).
  • Standard error categories are static-local singletons and thus register destructor through std::atexit. When category is accessed for the first time from another atexit handler. This might be a problem and can cause deadlocks (as any implicit locking). I had experience with this in the past.
  • System category is not able to match WinAPI error codes against POSIX error codes the same way Boost.System does this (something that was the whole point of this facility in the first place).
  • On MSVC12 (Visual Studio 2013) comparing error categories does not work across dlls. This is one of compilers supported by Boost. Boost.System had no such issues.

The sad part about <system_error> is that <filesystem> and future networking library (ASIO) both rely on it heavily, so both get a little bit broken on Windows.

Boost.Thread vs <mutex>, <condition_variable>, <shared_mutex>.

Until recently on Windows and MSVC std::condition_variable and std::mutex could cause deadlock when instantiated in a dll due to using lazy initialization internally. With MSVC14 (Visual Studio 2015) this should be fixed at least for std::mutex since it was rewritten to use SRW locks internally, but I am not sure about condition variables. MSVC12 (Visual Studio 2013) definitely has a lot of bugs here.

If you need a reader-writer lock, it might be very important to know if it favors readers or writers. Standard std::shared_mutex does not allow you to specify this behavior and according to the original proposal this was done because there is an algorithm that allows implementation to favor neither and try to prevent starvation of both (somewhat "fair" lock). Original implementation e.g. boost::shared_mutex follows this algorithm and is not based on pthread_rwlock_t (which usually favors readers due to requirements of POSIXas std::shared_mutex. Imo this means std::shared_mutex has a poor implementation on many systems. Although Boost implementation is not the fastest one either.

  • Why were locales not adopted for `std::filesystem` ? – einpoklum Feb 10 '18 at 23:26
  • @einpoklum Probably because they are redundant and only cause confusion for POSIX systems. This functionality basically existed for Windows only. –  Feb 10 '18 at 23:27
  • So, those seem like the platform-specific / OS-oriented parts of Boost. But these specifically could be held onto while other, more "pure" libraries are dropped in favor of the `std::` versions. Plus even these could be given a dust-over and made C++17-and-up only, and use `std::optional`, `std::variant`, lambdas, and so on. – einpoklum Feb 10 '18 at 23:30
  • @einpoklum I didn't use other parts of C++17 much since they were not available. But I doubt everything works correctly. I remember there were also issues with `std::regex_match` and `std::error_category` few years ago. Could be fixed now. –  Feb 10 '18 at 23:35