Re: [nowide] Future

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 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
>
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!

Artyom