GCC Lands Support For C++ File-System TS

[Kemosabe]

<trolling>
I read stuff like this and I am glad I switched to C#. I would like to say that C++ has done a good job at making itself irrelevant, but I just posted an image binarization library to github recently and I chose C++ purely for performance reasons. Great, its fast... but it can't even read in a PNG without a third party library. One of C++'s recent accomplishments is providing a standard threading api... "ain't nobody got time for that." While the C++ standards committee tries to fresh the language into something that looks like an old, gimped version of C#, I thinks its probably best to just jump into the future, today, and use the real deal. Congrats getting a standardized filesystem api.
</trolling>

So is this just a random collection of words or do you believe in what you're saying? I am not sure what the trolling tag is supposed to say ...

[tinko]

So is this just a random collection of words or do you believe in what you're saying? I am not sure what the trolling tag is supposed to say ...

The trolling tag means: "I want to throw something out which may or may not be my actual opinion but I don't want to be in a position, where I actually might have to defend my words and argue for a position."

[Zan Lynx]

The problem is that if you handled paths unencoded, you will have trouble doing case-insensitive name lookups, since that requires codec awareness. Qt can do that, but then has trouble with stuff that is wrongly encoded. Which is why it is relevant how they handle case-insensitive file lookups. Both macOS and Windows CAN do case-sensitive files, but usually doesn't, and not doing the same as native applications would not be nice and make the standard much less relevant.

If you need an encoded path, then encode it yourself. The problem with APIs that think they're smart by normalizing UTF-8 is that they utterly fail when the filesystem has a name that doesn't follow their nice rules.

[tambre]

This article is blatantly wrong, as pointed out here by the person who implemented the filesystem library.

[carewolf]

If you need an encoded path, then encode it yourself. The problem with APIs that think they're smart by normalizing UTF-8 is that they utterly fail when the filesystem has a name that doesn't follow their nice rules.

Well. The problem is that some filesystems requires encoding. For instance filenames are bytestrings in UNIX, but wchar_t strings in Windows, and on Mac are required to be normalized unicode strings, since file-name look up is done in locale aware unicode.

So for something like Qt that wants to act native, doing the encoding is essential to work as expected on Mac and Windows. The alternative is to try to do Linux/Unix like filenaming on Windows and Mac, that should work on Mac but be non-standard, and works sometimes on Windows, depending on the backing file-system (at least Microsoft has been working on that, with both this standard and their Linux layer).

[discordian]

Filesystems don't encode, and should not encode, and lower lever frameworks should not either. Aslong you don't have some stupid scheme where you encode filenames differently than the filesystem does, you don' t need any fragile logic dealing with conversions.
The only system that would be responsible for those conversions would be at the user-interface level, everything else just gets correctly encoded names which means different things depending on platform.

On topic: finally, feels like ages. Did write my own (boost v3) compatible implementation for some embedded system where C++-Exceptions are disabled, thanks to sane interface decisions this is possible.

[pal666]

Well. except for the file system which is not POSIX. So for the relevance of this article, it isn't.

well. except apple is certified unix 03, which is posix:2001 including filesystem
btw, linux supports apple filesystems, so by extension linux should also be "not posix"
but it is irrelevant since standard says

Implementations are not required to provide behavior that is not supported by a particular file system. [ Example: The FAT file system used by some memory cards, camera memory, and floppy disks does not support hard links, symlinks, and many other features of more capable file systems, so implementations are not required to support those features on the FAT file system but instead are required to report an error as described above. —end example ]

[pal666]

I read stuff like this and I am glad I switched to C#.

i am too glad stupid people are switching away

I would like to say that C++ has done a good job at making itself irrelevant, but I just posted an image binarization library to github recently and I chose C++ purely for performance reasons.

by this comment you made you irrelevant

but it can't even read in a PNG without a third party library.

but it can read png on more platforms than c#

One of C++'s recent accomplishments is providing a standard threading api... "ain't nobody got time for that." While the C++ standards committee tries to fresh the language into something that looks like an old, gimped version of C#, I thinks its probably best to just jump into the future, today, and use the real deal. Congrats getting a standardized filesystem api.

well, c# has no standard(c++-grade iso standard) at all, so it lags behind c++ in standardization

[pal666]

Well. The problem is that some filesystems requires encoding.

c++17 standard says "Permissible characters, case sensitivity, maximum length, and the disallowed names are implementation-defined"
api accepts any of char, char16_t, char32_t, wchar_t

For instance filenames are bytestrings in UNIX, but wchar_t strings in Windows

this is a common misconceptions. windows filenames are utf-16, which happens to be represented by 16-bit wchar_t on windows. but it is variable-length encoding just like utf-8, but with fucked up non-8-bit elements(combines worst qualities of utf-8 and utf-32)

[bpetty]

i am too glad stupid people are switching away

Personal attacks make me sad... sad to see someone bite the Troll bait.

well, c# has no standard(c++-grade iso standard) at all, so it lags behind c++ in standardization

A basic google search seems to suggest otherwise: "It was developed by Microsoft within its .NET initiative and later approved as a standard by Ecma (ECMA-334) and ISO (ISO/IEC 23270:2006)."

Now I am feeling a little guilty. Sorry for derailing.