5 ms·

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 Va

by jmrm 1y ago

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 1y ago
> 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)
- dgfitz 1y ago
  Correct, they have been around for a lot longer than rust.
- jmrm 1y ago
  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 :)
- gpderetta 1y ago
  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.
  - jcelerier 1y ago
    I agree, I was stuck on boost::optional for a long time for this reason, and I only use boost::variant2 for my variant needs, although code can still build with std:: in case a customer really does not want boost
forrestthewoods 1y ago
std::variant is an abomination that should never be used by anyone ever. Everything about it is sooooo bad.
- nrclark 1y ago
  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.
  - coffeeaddict1 1y ago
    It doesn't have proper pattern matching (you have to use a visitor class or the weird overload trick), and it sucks for compile times. It should have been a language construct rather than adding it to std, but the committee is often too scared to touch the language because they are stubbornly unwilling to break backwards compatibility.
  - tialaramex 1y ago
    C++ is a proud New Jersey language. So the priority has been and continues to be ease of implementation. If it's tricky to make it work right, don't sweat it - the users (in this case that's us programmers) will put up with it not working right. std::variant has valueless_by_exception - the C++ language wasn't able to ensure that your variant of a Dog or a Cat is always, in fact, a Dog or a Cat, in some cases it's neither so... here's valueless_by_exception instead, sorry.
    - Maxatar 1y ago
      Ease of implementation was not the issue here, on the contrary the easier implementation would have guaranteed that std::variant<Dog, Cat> always contains a Dog or a Cat. The issue was performance in that guaranteeing a Dog or a Cat requires dynamic storage duration if either of Dog or Cat has a throwing constructor. If neither Dog or Cat have throwing constructors, then std::variant<Dog, Cat> is guaranteed to always be a Dog or a Cat.
fair_enough 1y ago
"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.
- jmrm 1y ago
  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!
  - fair_enough 1y ago
    A lot of those design decisions in OSes were influenced by hardware limitations of home computers in the 1970s and 1980s. UNIX may have been around since '71, but Windows NT was designed to expose an API similar to DOS-based Windows 95 (the Win32 API), which in turn was designed around backward compatibility with MS-DOS, which in turn was designed to mimic other other "DOS" OSes from other companies in the late 70s. This ultimately traces back to a time when consumer-grade hardware just couldn't handle all the features we now take for granted, like virtual memory and preemptive multitasking, or even floating point math. However, Windows NT was also written after machines capable of running Unix cost less than a BMW so a lot of the good folks in Redmond during the early 90s took some liberties to improve on some fundamental design flaws of UNIX. 1. "Everything is a file" is very flexible for writing server applications where the user is expected to know and trust every program, but it is potentially harmful to expose devices as files to non-technical users. Nowadays with UEFI, you can even pipe /dev/zero to /dev/mem or /dev/port and brick your motherboard. There was a patch for this, but there are old servers running old Linux versions in the wild that can be permanently bricked. 2. Arguably, exposing such a wide range of signals to a userland program for it to handle is a design flaw, like the memory fault signals SIGSEGV and SIGBUS. They were not designed for IPC or exception handling, but they ended up being used that way by a lot of developers over the years. I won't start a war to make the case because I can see both sides on that, but #3 below is not controversial at all. 3. NTFS ACLs are a big improvement over UNIX-style ugo-rwx permissions. FWIW, they're also easier to work with than POSIX ACLs. Just something to think about: the Windows way is radically different because compatibility with ye-olde DOS running on 68k CPUs ruined it in some ways, but in other ways its design was driven by learning from UNIX's mistakes. despite the confusing name, Win32 is not just a 32-bit libc, it's a 64-bit libc on 64-bit Windows.
flykespice 1y ago
> 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 1y ago
  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.
GuB-42 1y ago
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.
loeg 1y ago
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.

by jmrm 1y ago

jcelerier 1y ago

> 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)

dgfitz 1y ago
Correct, they have been around for a lot longer than rust.
jmrm 1y ago
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 :)
gpderetta 1y ago
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.
- jcelerier 1y ago
  I agree, I was stuck on boost::optional for a long time for this reason, and I only use boost::variant2 for my variant needs, although code can still build with std:: in case a customer really does not want boost

forrestthewoods 1y ago

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

nrclark 1y ago
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.
- coffeeaddict1 1y ago
  It doesn't have proper pattern matching (you have to use a visitor class or the weird overload trick), and it sucks for compile times. It should have been a language construct rather than adding it to std, but the committee is often too scared to touch the language because they are stubbornly unwilling to break backwards compatibility.
- tialaramex 1y ago
  C++ is a proud New Jersey language. So the priority has been and continues to be ease of implementation. If it's tricky to make it work right, don't sweat it - the users (in this case that's us programmers) will put up with it not working right. std::variant has valueless_by_exception - the C++ language wasn't able to ensure that your variant of a Dog or a Cat is always, in fact, a Dog or a Cat, in some cases it's neither so... here's valueless_by_exception instead, sorry.
  - Maxatar 1y ago
    Ease of implementation was not the issue here, on the contrary the easier implementation would have guaranteed that std::variant<Dog, Cat> always contains a Dog or a Cat. The issue was performance in that guaranteeing a Dog or a Cat requires dynamic storage duration if either of Dog or Cat has a throwing constructor. If neither Dog or Cat have throwing constructors, then std::variant<Dog, Cat> is guaranteed to always be a Dog or a Cat.

fair_enough 1y ago

"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.

jmrm 1y ago
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!
- fair_enough 1y ago
  A lot of those design decisions in OSes were influenced by hardware limitations of home computers in the 1970s and 1980s. UNIX may have been around since '71, but Windows NT was designed to expose an API similar to DOS-based Windows 95 (the Win32 API), which in turn was designed around backward compatibility with MS-DOS, which in turn was designed to mimic other other "DOS" OSes from other companies in the late 70s. This ultimately traces back to a time when consumer-grade hardware just couldn't handle all the features we now take for granted, like virtual memory and preemptive multitasking, or even floating point math. However, Windows NT was also written after machines capable of running Unix cost less than a BMW so a lot of the good folks in Redmond during the early 90s took some liberties to improve on some fundamental design flaws of UNIX. 1. "Everything is a file" is very flexible for writing server applications where the user is expected to know and trust every program, but it is potentially harmful to expose devices as files to non-technical users. Nowadays with UEFI, you can even pipe /dev/zero to /dev/mem or /dev/port and brick your motherboard. There was a patch for this, but there are old servers running old Linux versions in the wild that can be permanently bricked. 2. Arguably, exposing such a wide range of signals to a userland program for it to handle is a design flaw, like the memory fault signals SIGSEGV and SIGBUS. They were not designed for IPC or exception handling, but they ended up being used that way by a lot of developers over the years. I won't start a war to make the case because I can see both sides on that, but #3 below is not controversial at all. 3. NTFS ACLs are a big improvement over UNIX-style ugo-rwx permissions. FWIW, they're also easier to work with than POSIX ACLs. Just something to think about: the Windows way is radically different because compatibility with ye-olde DOS running on 68k CPUs ruined it in some ways, but in other ways its design was driven by learning from UNIX's mistakes. despite the confusing name, Win32 is not just a 32-bit libc, it's a 64-bit libc on 64-bit Windows.

flykespice 1y ago

> 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 1y ago
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.

GuB-42 1y ago

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.

loeg 1y ago

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.