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

(www.collabora.com)

Show context

quietbritishjim ◴[07 May 25 08:58 UTC] No.43913531[source]▶

I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is trivial compared to the alternative of creating and using wrapper types - regardless of whether I'm using Rust or C++. And the cost of visual noise of wrapper types, already higher just at the writing stage, then continues to be a cost every time you read the code. It's just not worth it for the very minor benefit it brings.

(Named parameters would definitely be great, though. I use little structs of parameters where I think that's useful, and set their members one line at a time.)

I know that this is an extremist view, but: I feel the same way about Rust's borrow checker. I just very rarely have problems with memory errors in C++ code bases with a little thought applied to lifetimes and use of smart pointers. Certainly, lifetime bugs are massively overshadowed by logic and algorithmic bugs. Why would I want to totally reshape the way that I code in order to fix one of the least significant problems I encounter? I actually wish there were a variant of Rust with all its nice clean improvements over C++ except for lifetime annotations and the borrow checker.

Perhaps this is a symptom of the code I tend to write: code that has a lot of tricky mathematical algorithms in it, rather than just "plumbing" data between different sources. But actually I doubt it, so I'm surprised this isn't a more common view.

replies(6): >>43913574 #>>43913623 #>>43913644 #>>43913894 #>>43914148 #>>43914163 #

lmm ◴[07 May 25 09:20 UTC] No.43913644[source]▶

>>43913531 #

> 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 them?

> the cost of visual noise of wrapper types, already higher just at the writing stage, then continues to be a cost every time you read the code. It's just not worth it for the very minor benefit it brings.

I find wrapper types are not a cost but a benefit for readability. They make it so much easier to see what's going on. Often you can read a function's prototype and immediately know what it does.

> Certainly, lifetime bugs are massively overshadowed by logic and algorithmic bugs.

Everyone claims this, but the best available research shows exactly the opposite, at least when it comes to security bugs (which in most domains - perhaps not yours - are vastly more costly): the most common bugs are still the really dumb ones, null pointer dereferences, array out of bounds, and double frees.

replies(2): >>43913941 #>>43914141 #

1. davemp ◴[07 May 25 10:48 UTC] No.43914141[source]▶

>>43913644 #

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.

replies(1): >>43915208 #

2. j16sdiz ◴[07 May 25 13:13 UTC] No.43915208[source]▶

>>43914141 (TP) #

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.

replies(1): >>43915337 #

3. bluGill ◴[07 May 25 13:22 UTC] No.43915337[source]▶

>>43915208 #

I wrote such a type library myself, and it worked great. However we eventually realized it was the wrong answer because you so commonly want to display that thing and nobody wanted to write each widget to have a different api for each other the thousands of different types in my library.

The current system is a runtime system which has one type, and you set what the unit system is in the constructor. However it means adding a meter to a gallon is a runtime error.

replies(1): >>43922474 #

4. int_19h ◴[08 May 25 02:13 UTC] No.43922474{3}[source]▶

>>43915337 #

Er... why would you need a different API for this? Why not just convert to unitless at the point where the number flows into the UI?

Or better yet, parametrize the UI library so that it can display any unit automatically. It could even pull the metadata (like the string for the unit) from the template, so that e.g. binding a kg<float> value to a label would automatically show as "42 kg" etc.

replies(1): >>43925481 #

5. bluGill ◴[08 May 25 12:29 UTC] No.43925481{4}[source]▶

>>43922474 #

At the point where you convert to unitless you lose all the benefit of strong types. Which is a trade off maybe you can accept. One part of that trade off that you are adding the ability to convert to unitless and thus making it easy to use unitless where you shouldn't.

there are many different ways to implement unit systems. I know of 3 other attempts someone made on just our project to make units work before we settled on this one. There are trade offs and I don't mean to imply I have presented the correct answer for your problem. Only that because of many other reasons (not stated because of NDA) this is the best compromise for us. Your problem is different and you will need to find your own solution. There are lots of possible answers and each has a set of pros/cons. If your problems are simple than you can find an off the shelf answer, but if you need to do complex things you will need to consider what you really want.

replies(1): >>43930828 #

6. int_19h ◴[08 May 25 20:14 UTC] No.43930828{5}[source]▶

>>43925481 #

I understand that there may be other requirements that dictate the design. It's just that the specific one that you gave originally - that of displaying the values - strikes me as something that shouldn't be difficult even when you have units reflected statically in the type system.

> At the point where you convert to unitless you lose all the benefit of strong types.

Right, but if you do that right before it actually gets displayed, then it shouldn't be a problem since all actual computations have been performed already? I mean, you also need to convert numbers to text to render them, so all the same arguments apply.

So e.g. in the "ideal" desktop app using MVVM, that would happen on the boundary between the model and the view-model.

> One part of that trade off that you are adding the ability to convert to unitless and thus making it easy to use unitless where you shouldn't.

But any typed unit-of-measure system inherently has such an ability if it tracks units properly for arithmetic operations - you just divide by 1 of the same unit to get a unitless value. E.g. in F#:

   let v = 10<m/s>      // in m/s
   let n = v / 1<m/s>   // unitless

↑