Is it just me or is the C++ STL.... a chaotic mess?

@halfflat it's just that the more I read, the more often I see things that were changed and even removed in newer versions

Or the return type of some function is actually just a using ... = ...;

@r20408e122449d I mean yeah, but comparing it to the C#/.NET library I've worked with in the past it's like walking a maze that changes as you traverse it

I found STL really well designed overall. What do you not like about it?

Apart from a few instances and "REDONE"s, nothing spectacularly chaotic popped up for me. Where did you find it fucky?

@RememberMe @3rdWorldPoison

Maybe I have this impression because I work with a bunch of legacy software, but I feel like every revision some parts get changed and deprecated left and right, like auto_ptr and I have to juggle around it

Then I see components which work just as they do right now in C++17, but not in C++20 and so on

I guess this stems into the way C++ does namespacing and types which I just find to be... ugly?

like std::filesystem::last_write_time returns a std::filesystem::file_time_type

but that file_time_type is actually just

using file_time_type = std::chrono::time_point</*trivial-clock*/>;

but since C++20 it's actually

using file_time_type = std::chrono::time_point<std::chrono::file_clock>;

I might just have a biased view on this, especially because I don't like C++ in general, but man I miss the intuitivity of C#/.NET

@LotsOfCaffeine I defence of c++, c# had many years of others mistakes to learn from and the designer of c# is also the developer behind Turbo Pascal so he had lots of language design experience.

C and C++ was leading the way and that means testing things out.

@Voxera I mean yeah that's fair, a lot of the weird things in C++ came to be out of historical reasons, but I still want to replace them

@LotsOfCaffeine I understand, the problem is how you do so without breaking all existing software.

C# also have some problems.

But I do look forward to the “nullable reference types” where null is not no longer is a valid value for objects unless explicitly declared so.

That feature is mind blowingly powerful :P

@Voxera that feature is neat, and it's already here (was added in C# 8)
It does fall apart when you're doing serialisation though, in that case you might still wanna null check every now and then but other than that it's a great feature.
I'm not completely on board with all the new features form C# 8 and 9 though.

And I wasn't saying that C# is without its problems, I mean the fact that an Array T[] implements ICollection<T>, but hides the Add(T) method from the user because it makes no sense on an array. But when you cast the object to an ICollection<T> you can call Add which results in a NotSupportedException.

Or how the rather new Span types implement foreach compatibility feels a bit... hacky