Boost logo

Boost :

From: Artyom Beilis (artyom.beilis_at_[hidden])
Date: 2019-12-02 19:55:41

On Mon, Dec 2, 2019 at 11:26 AM Alexander Grund via Boost
<boost_at_[hidden]> wrote:
> 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,
> MinGW)
> - 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,
> sorry)
> - 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)
> Regards,
> Alex
Hello Alex,

I want to be second on that on what you said. If somebody can take the
maintainance of the library for the
Boost it is you.

I really see the effort you put into and I'm really glad.

If you volunteer to maintain and continue to improve this small
library this would be amazing

@Peter Dimov

Since from what I understand Alex's version already includes that
reviewfixes branch
it may be good idea to start from his version.

Thank You!


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