std::filesystem wow

[Michael Powell]

Hello,

Congrats to the Boost team and Filesystem contributors for this promotion. I haven't worked with it much, YET, but the bit that I have worked with std::filesystem, and boost::filesystem before that, it really does make life working with FS concerns so much easier. Cannot give enough :+1: thumbs ups where that's concerned.

Cases in point, I've done extrapolation of absolute, relative, path composition with the "/" operator overload, creating directory(ies), removing files and removing all files/directory(ies) so far. There also appears to be support for Unicode, which is amazing, IMO.

Best,

Michael Powell

[Alf P. Steinbach]

On 11.12.2018 16:40, Michael Powell wrote:
>
> Congrats to the Boost team and Filesystem contributors for this promotion. I haven't worked with it much, YET, but the bit that I have worked with std::filesystem, and boost::filesystem before that, it really does make life working with FS concerns so much easier. Cannot give enough :+1: thumbs ups where that's concerned.
>
> Cases in point, I've done extrapolation of absolute, relative, path composition with the "/" operator overload, creating directory(ies), removing files and removing all files/directory(ies) so far. There also appears to be support for Unicode, which is amazing, IMO.

Yes, it's much better now. :)

But.

One reason for Boost Filesystem was that the C++03 (and now with
hindsight we know, C++14 and earlier) standard library couldn't handle
non-ASCII filesystem item names in Windows in a portable way.

Unfortunately already in its Boost incarnation it partially failed at
that objective, by (1) assuming Windows ANSI encoding as the default for
narrow strings, and by (2) dropping special support for MinGW g++'s lack
of wide string based stream constructors in the 3rd version. And it
appeared there was so much to fight about with this library, that
attention to detail suffered. Hence (IMO) there are some very baffling
and frustrating oversights, e.g. no reliable functionality for finding
the executable's path, which makes it difficult to reliably and portable
access files distributed with the executable.

The C++17 standardization of `std::filesystem` is AFAIK the first time
there has appeared text like “for Windows” and “for POSIX” in the C++
standard, but still it was IMO a change in the right direction. The
system specific wording is mainly assurance that the library is
efficient regardless of platform. The standardization got rid of the
proposal's notion of system specific iostream constructors (with wide
string arguments in Windows) by outfitting the iostreams with
constructor overloads that take `std::filesystem::path` arguments.

However, the standardization kept the ungood assumption of
configuration-specific and limited Windows ANSI encoding for narrow
text. That means that for modern UTF-8 based code it's VERY easy to
inadvertently invoke the wrong encoding assumption with std::filesystem.
And worse, the `std::filesystem::u8path` function, the only way to
reliably and portably create a path object from an UTF-8 encoded narrow
string, will be deprecated in C++20.

Now this on-the-surface-sabotage-like deprecation *may* have something
to do with a proposed distinct UTF-8 narrow character type, and it *may*
have something to do with a vision of a replacement for the current
general encoding conversion support (`codecvt`, deprecated in C++17),
but it looks bad, it looks like a signal that one should forget about
basing code on std::filesystem because it may stop working in 2023.

:(


Cheers!,

- Alf

[Alf P. Steinbach]

On 11.12.2018 17:44, Alf P. Steinbach wrote:
> Windows ANSI encoding as the default for narrow strings

I meant in Windows. Sorry for hasty typing.

Cheers!,

- Alf

[kiiw...@gmail.com]

Yes and since Micro$ always has it's head up its ass it will be a new source of vulnerabilities.
Exactly what we needed. Not being able to switch on std::string…
Actually both are useful. I just need one more than the other I guess