Re: [nowide] Future

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, 
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 https://github.com/Flamefire/nowide.

It also has proper Github release integration ("Boost" and standalone 
version) with an extra asset for the (updated) docu: 
https://github.com/Flamefire/nowide/releases

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: 
https://bugzilla.redhat.com/show_bug.cgi?id=1502584
- 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