[jmrm]

I really like how some good structures used by other languages, specially Rust and Zig, have been added to the newer C++ standard.

The Result, Optional, and Variant are really sweet for day-to-day use of the language, and those in-process standard libraries of SIMD operations, BLAS mathematical functions, and the the execution library looks really cool, specially as standard.

I would like C++ would be a little more "batteries included" in some ways, like having a basic standard for signals, networking (just handling sockets would be a huge thing), and some basic system calls.

[jcelerier]

> I really like how some good structures used by other languages, specially Rust and Zig, have been added to the newer C++ standard. The Result, Optional, and Variant are really sweet for day-to-day use of the language, and those in-process standard libraries of SIMD operations, BLAS mathematical functions, and the the execution library looks really cool, specially as standard.

for Optional and Variant they both were basically standardized versions of boost.optional & boost.variant, which exist since 2003 and 2002 respectively. Most of the time you can just change boost:: to std:: and it works exactly the same ; for many years software I develop could switch from one to another with a simple #ifdef due to platforms not supporting std::optional entirely (older macOS versions, pre 10.14 IIRC)

[gpderetta]

Often the std flavored implementation is inferior of the boost one. Support for optional references has only be added to the draft standard recently, while bossy has had it since forever.

[dgfitz]

Correct, they have been around for a lot longer than rust.

[jmrm]

I knew some changes (like STL containers) came from Boost, but I didn't know those also came from there, and specially since such a long time!

That means I need to look more Boost documentation :)

[fair_enough]

"I would like C++ would be a little more "batteries included" in some ways, like having a basic standard for signals, networking (just handling sockets would be a huge thing), and some basic system calls."

Besides basic handling of TCP sockets and the Unix-style "Ctrl-c" keyboard interrupt, none of the stuff you're asking for is portable across different platforms. I'm not saying it's a bad idea, just that there is no one single universal standard for what an OS should do and what knobs and levers it should expose, or at least one that everybody follows.

Linux has non-trivial deviations from the POSIX spec, and even FreeBSD and OpenBSD have deviations. POSIX has its own compliance test suite that it runs to award certification of compliance, but it's not open source and it you need to pay a fee for it.

All of that however, is a drop in the bucket compared to making an API that exposes all the knobs and levers you want in a way that behaves exactly the same on Windows which barely has any architectural resemblance to UNIX. For exmaple, NTFS is case-insensitive by default and has nothing resembling the UNIX style of file permissions. Or more importantly, signals do not exist on Windows; something resembling signals for keyboard interrupts exists, but stuff like SIGHUP and SIGBUS does not. I'm talking the kind of known caveats that come with using a POSIX-compatibility layer on Windows, e.g. Cygwin.

I think if I get much deeper than that I'm just being pedantic, but even Python code behaves differently on Windows than it does on all the POSIX-like OSes out there.

[gpderetta]

Asilo Is a portable and efficient network abstraction. It was being tweaked for standardization for the last 15 years, before being suddenly voted out.

[zamadatix]

There's no universally adopted OS standard for a lot of the stuff in the stdlib but C++ sans std::string, a large portion of things under std::ios_base, most all of concurrency (e.g. std::thread), std::filesystem, and so on would be relatively shit in comparison.

As much as possible in the stdlib should behave the same across as many targets as possible. That's about where the relevance ends in my mind.

[jmrm]

I knew about the difference they have between UNIX-like OSs in the usage of different signals (and the System V vs BSD battles, between others), but I didn't know Windows didn't have a similar system (I haven't done too much low-level in Windows).

Thanks for the long comment!

[GuB-42]

Some of them date back from way before Rust and Zig. I am thinking about Qt and Boost.

Boost in particular is like a testing ground for future C++ standards, with many of the "batteries" you want included. And it is already C++.

Of course, Rust is a huge influence nowadays, and it sparks a lot of debates on the direction C++ should take. I think less so with Zig, which is more C than C++ in spirit, but every good idea is good to take.

[flykespice]

> I would like C++ would be a little more "batteries included" in some ways, like having a basic standard for signals, networking (just handling sockets would be a huge thing), and some basic system calls.

Isn't Boost library basically that? C++ has been slowly adopting freatures from it to its standard library.

[zamadatix]

C++ has been adopting features from a lot of different libraries into the stdlib. These libraries don't always do it "The Boost Way™", even when Boost has an equivalent library. Boost has a lot of good stuff though, it's just a little farther from being "std++, why care about std?" than commonly advertised.

[loeg]

I wish C++'s optional was less of a compromise. It would be great if it had specialization for sentinel values, like Rust. As-is it can be pretty wasteful in data structures.

[forrestthewoods]

std::variant is an abomination that should never be used by anyone ever. Everything about it is sooooo bad.

[spacechild1]

That's a bit hyperbolic. Sure, it's not exactly ergonomic, but that doesn't mean I can't use it. One thing that bugs me is that there is still no overload helper in the standard:

    // helper type for the visitor
    template<class... Ts>
    struct overloads : Ts... { using Ts::operator()...; };

Of course, having true pattern matching would be much nicer. At least there's a proposal: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p26...

[SJC_Hacker]

Kill me, but I never saw the point over abstract base classes and polymorphic behavior defined in the subclasses.

Now purists will scream “compile time optimization!”, but in reality std::variant is inplemeted very múch líne a vtable. There was a good talk at Cppcon a few years ago on this issue. In particular, they found no difference in performance.

[nrclark]

out of curiosity, can you elaborate on that a bit? I've shipped std::variant in a few designs and it's been OK, but maybe I didn't use it deeply enough to see issues.