Redpill me on std::filesystem

At the start, but not anymore.

I see, so how is dirent.h better?

Every single time.

Read the page you posted a picture of. It's pretty simple.

I'm not saying it is, you asked for a C way so I gave one.
I guess compared to std::fs it can be simpler to use though, but as you said you'd need to work with pointers, structs & shit.

Sherley there's a reason you dislike C++

Eh, like I said I'm not this guy , was just letting you know about dirent.h

I don't mind C++ but I'm a lot more comfortable with C (but that's probably because there's not as much needed to learn to be a good C programmer compared to being a good C++ programmer)

With C you can learn it and eventually one day maybe even master it, but with C++ there's always new shit being added, code you wrote a year ago could be completely unneeded and replaced with some newly added thing to the STL... you can't really ever master it since by then there's something new you have to learn

It's not really a bad thing, some people probably like that about it, but I just prefer sticking with what I already know.

So how do you pronounce std?
>standard
>ess tee dee
>stud
Everyone in cppcon vids says stud.

just like use win32

Stud aka C++ programmers

>and how the fuck do I use it?
Why don't take a fucking look at the website in your image

You literally can't use c++ with out it.

You basically have C.

You do realize that iterators are semantically pointers, right

But they're not naked pointers.

>not naked
Is this supposed to be a good thing?

Const null pointers are best pointers.

Yes, naked pointers are ambiguous. For instance, when interfacing somebody else's code at the workplace, I never delete raw pointers. Just to spite people.

>with the exception of Winblows
>using C library in C++ when there is standard C++ library equivalent
why?

Because, on average, C produces faster code. It's also portable - optimised for UNIX and Linux (everything else is bloat, pretend it doesn't exist).

>naked pointers are ambiguous
No they're not. They're not wearing any clothes so you can see their gender clearly. If anything they're the least ambiguous and most lewd pointers.

>Linux
>Not bloated as fuck
LMAO

Yes the syntax is clear but their use is not. A T* can be used for anything and everything ranging from arrays to factories to thread handles, etc...

user, you don't seem to get it.
I'm not being serious and I'm not actually arguing against you. I actually agree with you.

Wow I need more coffee

>C produces faster code
No
>portable
dirent.h is POSIX only. C++ filesystem is more portable.

It's good. read the reference. super convenient access.

>POSIX
People Only Should Install linuX
Yeah sounds about rite

I read "standard" every time someone abbreviates "sexually transmitted disease"

>Doctor my groin Is swollen and hurts
>hmm you may have STD's
>BUT I only use boost
epic, simbly ebin

>Doctor my groin Is swollen and hurts
>hmm you may an STI
>BUT my interrupt flag isn't set!

Epic programmer jokes! Us coders, eh?

std::filesystem only really worked well under linux because boost::filesystem was designed with Linux in mind. So in c++17 they added extra stuff they forgot to add to it to make it work well under Windows.
The absolute state of C++ and Boost.

A manager, a mechanical engineer, and an IT guy are driving a car in the empty Arizona desert.
Suddenly, smoke comes out of the engine and they come to a halt.
The manager says "Let's work together and we will probably come up with a solution sometime."
The engineer says "Get my wrench and let's disassemble the engine down to the bolts!"

The IT guy flips the rear view mirror several times and the car revs up again.

Boost is independent from the standard. Not sure how this is the standards fault, they literally improved it.

>dirent.h is POSIX only. C++ filesystem is more portable.
Not really, there's dirent.h ports for pretty much every platform under the sun, POSIX or not (hell even Amiga/Atari has dirent.h)
Meanwhile C++ filesystem is only available for that small amount of platforms that have C++11 support.

Oh wait it was C++17 not 11, so an even smaller number then.

>C++11 support
You don't require a compiler, just runtimes.

Yes. When I started C++ I thought it just meant standard. Now I know better an know that it was someone on the inside cleverly putting out a warning.
Use of std:: anything but containers especially will pollute your code rapidly.

You'll also find that if you were to accept this pollution for whatever reasons there's better libraries for virtually anything the standard library does. I don't remember if they've fixed it yet but vector doesn't even have sbo. That's how dire it is.

They're not. But in many cases they may be.

They are literally modeled off pointers.

>even have sbo
whats sbo

>I don't remember if they've fixed it yet but vector doesn't even have sbo.
This is not a standards issue.

>small amount of platforms

More like, "only platforms that matter". Face it user, you're not writing anything that's going to be running on obscure platforms, assuming you're writing anything at all.

Because of not allowing iterator invalidation on move it restricted implementations to not have SBO in practice.
Of course they could have remidied that. Either way I'm picking on vector because aside from std::array which is trivial it's the best datastructure around. The one you'd be the most inclined to use. But even it is flawed.
Small buffer optimization. Basically instead of having a pointer to heap the object can contain a small buffer of elements on its own for efficiency. It's most common in string types but it's widely applicable and is a very important optimization for business logic code.
I think c++s strings have that actually, but not vector.

Also how the fuck is that not a standards issue? I don't understand. If the standard restricts implementers it damn well should be a standards issue.
This isn't the wild west. Implementers have to follow the standard.

You have to understand the standard does not imply any of these optimisations. GCC, clang, visual studio... All implement their own.
You should make some commits to GCC if you want.

Wouldn't the runtime still need support for the platform though? eg. with the dirent.h example the ports have to make use of Atari/Amiga/whatever system APIs, so wouldn't the C++17 STL need the same thing for std::fs to work with those APIs too?

>Face it user, you're not writing anything that's going to be running on obscure platforms, assuming you're writing anything at all.
Why would you think that? I guess you've never seen the bounties people are paying out for those platforms.

>Wouldn't the runtime still need support for the platform though? eg. with the dirent.h example the ports have to make use of Atari/Amiga/whatever system APIs, so wouldn't the C++17 STL need the same thing for std::fs to work with those APIs too?
No? Have you actually seen the source code

Well you seemed to know, that's why I was asking.
I don't really see how a runtime could work with XYZ platform without being updated for XYZs APIs, remember not everything is POSIX or whatever.

>if they took everything from boost everything they do would be great

Maybe I'm retarded but I genuinely don't get this. Is just this a very badly made joke about "turning it on and off again" or just flicking some switch until it starts working?

what about stdin stdout stderr?

I thought I had made myself perfectly clear. Excessively so even.
It's not legal (standards compliant) to do SBO in vector because of the move constructor to my knowledge.
Not within reason anyway. I have ideas but they imply pessimization for most cases.
Unless you have a standard to point to that changed this then you're wrong.

You could probably do it under the as-if rule if you manage to cover every usage site somehow. It's something I hope they do. But that's still a problem with the standard even if they manage. Because it still doesn't fire where you want it by necessity.

Okay strings are movable and have SSO (usually). If my understanding is correct that std::vector is to have an arbitrarily sized buffer on the stack, then what's the problem with move semantics?

The address of elements can change if you move an SBO vector. This is currently invalid for vector.

How so? For instance, vector warns you that resizing may invalidate iterators and that's alright.

en.cppreference.com/w/cpp/container/vector#Iterator_invalidation
iterators are not invalidated on swap, this prevents SBO

Hey cool thanks for this

Yes but then they said that moving a vector doesn't do that.
So you can't. And you can't say 'vector says resize invalidates iterators so move can do that too'.
They tell you what does/doesn't happen. That's the point of the standard. Their choices influence what compiler authors can do.

What scares me the most is that the source I recall that taught me this expressed it as if it was a mistake/not a considered change. That means that anything that has a performance implication that's not obvious to the standards committee is at risk in C++.
And this situation should put their common sense into question.
But I don't have a good primary source.
Didn't even think of swap. But that's far more obvious.

The standard also guarantees it for move assignment/construction.
en.cppreference.com/w/cpp/container/vector/operator=#Notes
en.cppreference.com/w/cpp/container/vector/vector#Notes

Since it was already the case for swap it wouldn't make sense to not make this guarantee for moves as well.

because no one cares to port it to older compilers. there is a boost filesystem and it works on old c++

If there's a platform with no C++2a compiler, it's not worth developing for.

Yeah.