Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Matt Godbolt sold me on Rust by showing me C++

collabora.com

Post reply on HN
Print view View original

441–450 of 675 posts

Re: Matt Godbolt sold me on Rust by showing me C++

#441

Post by dietr1ch »

CJefferson wrote: post #206
jchw wrote: post #89

Earlier quoted context omitted.

Google has been doing a very similar, but definitely somewhat uglier, thing with StatusOr and Status (as seen in absl and protobuf) for quite some time. A long time ago, there was talk about a similar concept for C++ based on exception objects in a more "standard" way that could feasibly be added to the standard library, the expected class. And... in C++23, std::expected does exist[1], and you don't need to use excep…

I had a look. In classic C++ style, if you use *x to get the ‘expected’ value, when it’s an error object (you forgot to check first and return the error), it’s undefined behaviour! Messing up error handling isn’t hard to do, so putting undefined behaviour here feels very dangerous to me, but it is the C++ way.

`StatusOr::operator` there is akin to `Result::unwrap()`. On C++ unwrapping looks like dereferencing a pointer which is scary and likely UB already.

But as you learn to work with StatusOr you'll end up just using just ASSIGN_OR_RETURN everytime and dereferencing remains scary. I guess the complaint is that C++ won't guarantee that the execution will stop, but that's the C++ way after you drop all safety checks in `StatusOr::operator` to gain performance.

Re: Matt Godbolt sold me on Rust by showing me C++

#442

Post by bluGill »

CJefferson wrote: post #239
jchw wrote: post #228

Earlier quoted context omitted.

Assertions are debug-only. Exceptions are usually not guaranteed to be available and much of the standard library doesn't require them. You could std::abort, and that's about it. I think the issue is that this just isn't particularly good either. If you do that, then you can't catch it like an exception, but you also can't statically verify that it won't happen. C++ needs less of both undefined behavior and runtime e…

I agree these things would be better, but I don’t understand how anyone can think UB is better than abort. (Going to moan for a bit, and I realise you aren’t responsible for the C++ standards mess!) I have been hearing for about… 20 years now that UB gives compilers and tools the freedom to produce any error catching they like, but all it seems to have done in the main is give them the freedom to produce hard to debu…

A lot UB is things you wouldn't do anyway. While it is possible to define divide by zero or integer overflow, what does it mean. If you code does either of those things you have a bug in your code (a few encryption algorithms depend on specific overflow behavior - if your language promises that same behavior it is useful).

Since CPUs handle such things differently whatever you define to happen means that the compiler as to insert a if to check on any CPU that doesn't work how you define it - all for something that you probably are not doing. The cost is too high in a tight loop when you know this won't even happen (but the compiler does not).

No

Re: Matt Godbolt sold me on Rust by showing me C++

#444

Post by sham1 »

zaphar wrote: post #236
ryandrake wrote: post #157

Earlier quoted context omitted.

Error handling and propagation is one of those things I found the most irritating and struggled[1] with the most as I learned Rust, and to be honest, I'm still not sure I understand or like Rust's way. Decades of C++ and Python has strongly biased me towards the try/except pattern. 1: https://news.ycombinator.com/item?id=41543183

Counterpoint: Decades of C++/Python/Java/... has strongly biased me against the try/except pattern. It's obviously subjective in many ways. However, what I dislike the most is that try/except hides the error path from me when I'm reading code. Decades of trying to figure out why that stacktrace is happening in production suddenly has given me a strong dislike for that path being hidden from me when I'm writing my cod…

There should be a way to have the function/method document what sort of stuff can go wrong, and what kinds of exceptions you can get out of it.

It could be some kind of an exception check thing, where you would either have to make sure that you handle the error locally somehow, or propagate it upwards. Sadly programming is not ready for such ideas yet.

---

I jest, but this is exactly what checked exceptions are for. And the irony of stuff like Rust's use of `Result` and similarly ML-ey stuff is that in practice they end up with what are essentially just checked exceptions, except with the error type information being somewhere else.

Of course, people might argue that checked exceptions suck because they've seen the way Java has handled them, but like... that's Java. And I'm sorry, but Java isn't the definition of how checked exceptions can work. But because of Java having "tainted" the idea, it's not explored any further, because we instead just assume that it's bad by construction and then end up doing the same thing anyway, only slightly different.

Re: Matt Godbolt sold me on Rust by showing me C++

#446

Post by Shorel »

tialaramex wrote: post #240
PhilipRoman wrote: post #136

Earlier quoted context omitted.

>what are they supposed to do when there is no memory left Well on Linux they are apparently supposed to return memory anyway and at some point in the future possibly SEGV your process when you happen to dereference some unrelated pointer.

You can tell Linux that you don't want overcommit. You will probably discover that you're now even more miserable and change it back, but it's an option.

I did that and even with enormous amounts of free memory, Chrome and other Chromium browsers just die.

They require overcommit just to open an empty window.

Re: Matt Godbolt sold me on Rust by showing me C++

#447

Post by bluGill »

timschmidt wrote: post #405
qznc wrote: post #402

Earlier quoted context omitted.

Today a byte is 8 bits. That was not always the case back then, for example.

> I grew up with all the classic 8 bit micros Meaning that all the machines I've ever cared about have had 8 bit bytes. The TI-99/4A, TRS-80, Commodore 64 and 128, Tandy 1000 8088, Apple ][, Macintosh Classic, etc. Many were launched in the late 70s. By 1985 we were well into the era of PC compatibles.

in 1985 PC compatibles were talked about, but systems like VAX, and mainframes were still very common and considered the real computers while PCs were toys for executives. PCs had already shown enough value (via word processors and spreadsheets) that everyone knew they were not going away. PCs lacked things like multi-tasking that even then "real" computers had for decades.

Re: Matt Godbolt sold me on Rust by showing me C++

#448

Post by jovial_cavalier »

Hey, check this out:

#include

struct Price { double x; };

struct Quantity { int x; };

void sendOrder(const char *symbol, bool buy, Quantity quantity, Price price) {

    std::cout
}

int main(void) {

    sendOrder("GOOG", false, Quantity{100}, Price{1000.00}); // Correct

    sendOrder("GOOG", false, Price{1000.00}, Quantity{100}); // compiler error
}

If you're trying to get it to type check, you have to make a type first.

I don't appreciate these arguments, and view them as disingenuous.

Re: Matt Godbolt sold me on Rust by showing me C++

#449

Post by j16sdiz »

davemp wrote: post #399
lmm wrote: post #350

Earlier quoted context omitted.

> I just almost never have problems with this sort accidental conversion in practice. 95% of C++ programmers claim this, but C++ programs continue to be full of bugs, and they're usually exactly this kind of dumb bug. > will be noticed by literally just running the code once. Maybe. If what you're doing is "tricky mathematical algorithms", how would you even know if you were making these mistakes and not noticing the…

My current project is a huge C++ physics sim written over 15+ years. The most common and difficult to diagnose bug I’ve found is unit conversation mistakes. We likely wouldn’t even find them if we didn’t have concrete data to compare against.

There are a few unit library in C++.

Type checking in compile time is do-able with templates, even better with constexpr.

The problem is, of course, each library have its own set of rules and they won't interop with each other.

Re: Matt Godbolt sold me on Rust by showing me C++

#450

Post by bluGill »

pjmlp wrote: post #280
d_tr wrote: post #156

Earlier quoted context omitted.

C++ carries so much on its back and this makes its evolution over the past decade even more impressive.

Yes, people keep forgeting C++ was made public with CFront 2.0 back in 1989, 36 years of backwards compatibility, to certain extent.

C++ is C compatible so more than 50 years of backward compatibility. Even today the vast majority of C programs can be compiled as C++ and they just work. Often such programs run faster because C++ a few additions that the compiler can use to optimize better, in practice C programs generally mean the stronger rules anyway (but of course when they don't the program is wrong).
Post reply on HN