Boost logo

Boost :

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2019-12-02 09:26:07

Hi all,

I'm a user of this library AND developing under Windows. After the
library went supposedly stale I did a huge effort in the last 2 weeks to
bring it into shape:

- Implement CI: Appveyor (MSVC 2017/2019), Github actions (Linux, MSVC,
- Fix/Update & Test standalone version (requires C++11 though)
- Incorporate the whole reviewfixes branch and fix ALL remaining issues
from the reviewnotes but Boost.Build integration (no clue of Jamfiles,
- CMake based build with support for submodules (add_subdirectory),
installation and proper CMake targets (find_package(nowide) just works)
- Merge all my previously opened PRs and work through open issues fixing
more or less serious bugs (wrong return values, wrong behaviour on
corner conditions, formatting, line-ends, pointer confusion, warnings)

It can be found at

It also has proper Github release integration ("Boost" and standalone
version) with an extra asset for the (updated) docu:

I'm currently tackling the hardest part: The StdIO based filebuf which
turned out way harder than I though. I went over every single function
and checked it against the standard to avoid excessive flushes and make
sure it behaves as mandated. In the process I enhanced the test cases
greatly. In tests with MSVC I see big improvements on read/write
bandwidth which were complained about. They now match the std::fstream
performance *on average*, meaning they are sometimes even faster (for
small IO on my PC). However it is not done yet, as MinGW shows failures
so I got to double-check that I didn't miss anything.

So from my POV the library is/will be ready for inclusion into the next
Boost release (not the currently prepared one). Some points though:

- I'd need someone familiar with Jamfiles to check/fix them, especially
with the Jamfiles based CMake install
- Maintenance could be done by CMT, I could "lead" that though for a bit
of time. To ease that I added as much as possible to CI, including a
clang-format test (helps wasting review time about style discussion)
- The library scope should stay narrow, i.e. as-is. Feature requests
should be carefully considered, IMO it is pretty much complete. Again:
Ease of maintenance is key.
- Maintaining/Testing the standalone version should be continued, as
should be the CMake-based build. The library scope is narrow already,
and being able to use it standalone or as a submodule seems to be valuable.
- Require C++11 (not sure if this is acceptable, as the review didn't
point that out)
 Â  - Allows reduced dependencies (cstdint, scoped_ptr, static_assert)
 Â  - Standalone does already (dummy-headers redirect to std headers
which could be removed then)
 Â  - "Fuzzy" detection of `*::filesystem::path` to be not only
compatible to boost::filesystem for also to C++17

On the importance of this library:
- It has already been included into linux distros:
- Boost.Beast (as written) does not support UTF-8 against it advertising
it, it could use Boost.Nowide
- UTF8 codepages recently introduced IMO don't solve the problem: Unless
the standard codepage is UTF8, you'll never get UTF8 arguments to `main`
(unless I missed something)


Boost list run by bdawes at, gregod at, cpdaniel at, john at