Re: [Nowide] Opinion on slightly expanding the scope: LFS and more generic UTF-8 wide<->narrow conversion

From: degski (degski_at_[hidden])
Date: 2020-06-11 17:15:52

As a Windows user, I find this library less and less attractive. W10 is now
optionally fully Unicode/utf8, there is no reason to have anything else
than https://github.com/degski/Sax/blob/master/include/sax/utf8conv.hpp or
something like it and do perimeter conversions with these two functions,
specifically for windows. `std::filesystem` (and other bits of the STL)
does the right thing.  The original author worked at Microsoft at the time
and the code was published on the Windows blog, i.e.this is how it is done.

On Wed, 10 Jun 2020 at 02:24, Alexander Grund via Boost <
boost_at_[hidden]> wrote:

> Hi all,
>
> just wanted to gather opinions on 2 changes I'd like to make to
> Boost.Nowide which go slightly above the initial goal:
>
> 1. Make detail implementations of widen/narrow public.
>      - Mainly
>
> https://github.com/boostorg/nowide/blob/develop/include/boost/nowide/detail/convert.hpp
> which does templated conversion from/to wide strings which might be
> useful in generic contexts
>      - But also the underlying UTF decoding/encoding templates initially
> extracted from Boost.Locale
>
> https://github.com/boostorg/nowide/blob/develop/include/boost/nowide/detail/utf.hpp
>      I figured (and experienced) that those might be useful for
> consumers of Nowide as when they already use those UTF-8 APIs they might
> have other interface code which needs translation from/to wide strings,
> so exposing the existing code as a feature might make sense.
>      Basically this would put them under boost::nowide::utf namespace
> instead of in the detail namespace. I guess I don't need to retain the
> old ones or put in forwarding headers, do I?
> 2. As requested and implemented over 2 PRs (last one still open:
> https://github.com/boostorg/nowide/pull/104) Large files are now
> supported by boost::nowide::filebuf (technically only used on Windows)
> but the implementation is pretty portable as e.g. Tests on Unix do use
> boost::nowide::filebuf. This is done by implementing ftell/fseek via
> _ftelli64/ftello and configure-time checking availability.
>     As C++ is lacking C-Style file manipulation functions portably
> working with LFS I think a similar reasoning as above can be applied: It
> exists, it works and can be useful more generically so moving it out of
> the detail namespace might make sense.
>
> Opinions? Ideas?
>
> Regards, Alex
>
> PS: If anyone with filesystem experience would like to review #104 or at
> least glance over it, it would be appreciated.
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>