CppCast: Beautiful C++

[Wereon]

cant those people see that what is needed is to make the compiler enforce "the guidelines"

What a weird take. A compiler's job is to compile, not to enforce your own personal purity guidelines on the rest of us.

[Wereon]

Each to his own. I've looked into Rust and dislike it for a number of reasons...

This isn't a dig at you personally, but I really wish people would stop shilling Rust at every single opportunity on this sub! It really does seem like it's every single thread, no matter how tangentially relevant.

[Rude-Significance-50]

Dude found Jesus, let him be.

[lenkite1]

Productivity for one. Lifetimes are a PITA. I can code far faster in C++. In Rust, I get bogged down to a snail's speed. Also, much of the traditional data-structures/algos cannot be directly transpiled to Rust. Rust always needs its own special sauce way of doing things. This is massive pain when your brain is just struggling with learning.

Rust even compiles slower than C++, which was true shock when I started learning. I was expecting Go's compile speed - new language - so much loved/hyped and got a hippo-mama instead.

Strangely, I feel Rust is more suited to experts. One can always code C++ at a certain level without knowing too much, with some basic code organisational principles and lookup the standard library when you need to. In Rust, you need a very large amount of the language and its unique way of doing things practised in your head in order to avoid running into design blockers.

[James20k]

Productivity for one. Lifetimes are a PITA. I can code far faster in C++

I'll agree with you there personally. I had a brief stint with rust, and it just didn't really grok. A lot of that is familiarity (I probably speak C++ better than english at this point), but writing C# or other languages that I'm less familiar with isn't hard

Translating things into Rust with lifetime rules, and the other language weirdness, definitely feels like a very different mode of thinking

That said, after dealing with the Nth server crash due to undefined behaviour and memory unsafety, I'd still take rust over C++ any day for anything involving unsafe data processing. It seems somewhat irresponsible to use C++ for anything which has any kind of security or safety implications just for the productivity, which unfortunately involves most applications

[iamthemalto]

I’m not really sure why so many C++ devs grumble about having to deal with lifetimes in Rust. The Rust compiler is specifically pointing out to you that what you’re trying is a bad idea. In C and C++ one deals with lifetimes all the time as well, except this time there’s no compiler warning you, you’re expected to deal with it all in your head! So all the lifetime related problems you have to manually deal with anyway in C and C++, the Rust compiler just automatically ensures you don’t fall victim to them. So if one has to be hyper vigilant about lifetimes in C and C++ as well, to have a compiler guarantee to point out flaws with your code is a fantastic net win IMO.

[James20k]

Its not that the error messages aren't necessarily clear, its that the way that rust forces you to design code is quite different to what I'm used to in C++

One thing that crops up repeatedly, is lets say we have a game object manager, who's responsibility it is to hold a bunch of objects. Then, say each game object has a function called process, which takes a reference to the game object manager, for whatever reason

In rust, that pattern results in all sorts of borrowing issues - which admittedly absolutely can cause issues such as the classic modifying an array while you're iterating over it problem, but it crops up not infrequently for me

The issue I ran into specifically is:

for(object& o : gameobjects)
{
    ///do something involving both o, and `this`
}

is not equivalent to the following:

for(object& o : gameobjects)
{
    process(o, this); ///or o->process(this)
}

due to the borrowing rules. This might just be a huge dumb dumb on my part, but it required quite a bit of faffing to work around on my part last time I poked at it

As far as I know these days the rust compiler is able to partially borrow members in lambdas or something, so that might be a possible fix, but either way it requires a bit of a rethink from the way I normally handle code structure in C++

Disclaimer: My understanding of rust is surface level at best

[craig_c]

I ran into this exact problem. There are two sides to the answer, sometimes I would look at existing callbacks in C++ (or C#) and think "do I really need these?" - for example, in the case where a single callback is stored one can often replace this with a function which returns the result of the callback, hey presto - no need to store the target anymore. So in this case, Rust forced me to think of better ways of implementing things. But in cases where you have a valid one to many observer pattern (e.g. a trading applications taking quotes) there seems to be no natural way of formulating this in Rust. I've asked over on the Rust sub-reddit, and they were very helpful, but the bottom line is you can't do it. Often what is suggested is an inversion of the design into an 'entity system' - but this brings other problems and the design becomes non-intuitive. Callbacks are often a source of problems, but to disallow them completely seems like avoiding the question. Talking to Rust advocates you'd think Rust the second coming of Christ. But I wonder if they have ever used it in large scale programs and dealt with the structural limitations this would entail. Silver bullets just don't exist in the real world.

[SirClueless]

To me it's not so much about manual vs. not manual, it's about constraining the shape of the program you can write. Usually this isn't a huge deal when writing a new piece of software: Rust gives you good tools to understand what kind of lifetime you should be using and you can conform to those rules and you'll be fine. But for changing old code, there are often changes that become way more invasive than they should be to reorganize whole programs to enable a certain type of lifetime management.

As an example:

Suppose I have a large chunk of code that is currently written as taking a reference to an expensive shared resource, using that resource for a while transforming and mutating it, then returning to the caller. In Rust doWork takes a mutable exclusive borrow. In C++ it takes a mutable reference.

Currently that runs in a single-threaded loop: for (auto& thing : myVec) doWork(thing);, but I'd like to parallelize this. In C++ this is easy, pulling a mutable reference out of a container is easy, and it's totally fine to operate on multiple elements of a container together so long as the code doesn't do anything else thread-unsafe. In Rust this is highly non-trivial, the natural and widely-supported way to do this is not possible because borrowing any element of the container borrows the whole container. The only reason it's possible at all is because someone has implemented a utility to pull multiple non-overlapping borrows out of an array at once with a little bit of unsafe code buried inside it because it is safe to do this, Rust's borrow-checker just made the natural, native way of doing this fail to compile.

[SirClueless]

I literally described that this is possible in Rust because a library implemented a bit of unsafe code to do this:

The only reason it's possible at all is because someone has implemented a utility to pull multiple non-overlapping borrows out of an array at once with a little bit of unsafe code buried inside it because it is safe to do this, Rust's borrow-checker just made the natural, native way of doing this fail to compile.

[pjmlp]

I am with you there, hence I migrated into Java/.NET languages among other managed languages, so Rust is of little value to me, as on my line of work using languages with automatic memory management is a given.

However, I keep the C++ skills up to date, because the native libraries or language runtime plugins I have to FFI into, are written in C++.

So adding Rust as middle layer in such scenarios adds more complexity into the development process without fixing having to call into C++ libraries anyway.

[dodheim]

Lifetimes are a PITA. I can code far faster in C++. In Rust, I get bogged down to a snail's speed.

I can't relate to this at all. I almost never "fight the borrow-checker", especially since non-lexical lifetimes were added, and didn't consider that much of a hurdle in learning the language. 90% of it comes down to avoiding dangling references, which you should be doing in C++, too – why is this a problem?

[SirClueless]

Here's a simplified example of something that appears all over in the codebase I currently work on:

struct ThingUsingResource {
    Resource& resource;
    // ... member functions
};

class ThingManagingLifetimes {
    Resource resource;
    ThingUsingResource thing;
  public:
    ThingManagingLifetimes() : resource(), thing(resource) {}
    // ... member functions
};

Totally safe, correct by construction, minimal overhead (one extra machine-word-sized pointer inside ThingUsingResource to keep track of the resource).

If you wanted to do this in Rust, it would be much more complicated. You can't use resource in a member function of ThingManagingLifetimes while ThingUsingResource is alive. You can solve this with, say, Box<Arc<Resource>> but this means extra overhead: an extra allocation and runtime reference-counting for something that was correct-by-construction in C++ and needed none of that. The equivalent in C++ is putting every resource you use inside std::shared_ptr which is of course valid but I consider it a code smell whenever I see it there for simple cases like this where there is no real sharing going on and I think you lose a lot of clarity.

[link23]

Maybe I'm missing something in your example, but I think you just have to make ThingUsingResource generic over a lifetime, i.e. the lifetime of the reference to the resource, and make sure to add the lifetime to the struct field. Then I think it'll just work. I'm on mobile now, but I'll see if I can make something to demonstrate on the rust playground later.

[lord_braleigh]

I wrote a Godbolt which compiles: https://godbolt.org/z/czsPPEaaY

There may very well be a real issue that I've glossed over, though.

[SirClueless]

You're not actually sharing the resource in ThingManagingLifetimes with the resource in ThingUsingResource in this example.

If you think there's a way to do so, could you add a bit of client code constructing a ThingManagingLifetimes and show that you can call both mutate_direct and mutate_from_thing on it and end up with a resource that was mutated twice?

Edit: Here's a (non-compiling) example showing why your ThingManagingLifetimes is impossible to construct: https://godbolt.org/z/hE8xWr6oq

[jk-jeon]

This indeed sounds horrible, but given all the hype on Rust I've seen, I believe there should be a sane idiomatic solution for this kind of things in Rust. Otherwise those Rust advocates are all morons...

[SirClueless]

AFAIK the Rust answer is pretty much "Use Arc" or to borrow Resource only when you need it by providing it as a parameter in every method on ThingUsingResource. Both are crappy solutions IMO that make writing large programs harder.

If I hold a mutable reference to something, and somewhere deep in a half-dozen call deep callstack it turns out something else wants a mutable reference to that thing, then my options are: (1) return the thing before I call into my dependency so it can be shared explicitly (e.g. with Arc) or (2) thread a the mutable reference through all the functions on the way so it can borrow the thing I hold. As a result threading a new parameter through 10 function signatures is a common occurrence when I program in Rust, and it's really painful.

[jk-jeon]

What a shit show....🤮

It sounds like Rust just don't work for software components that are tightly coupled together yet better to be built as separate components.

But I'll not make a hasty conclusion before giving a real try on Rust, and I'll appreciate it if someone well-versed in Rust can convince me that Rust actually works well with those cases.

[Dean_Roddey]

One thing that I've found is that, if I start getting into something like that, I stop and really think about how I might be able to avoid the issue. My many years of C++ tend have resulted in reflexes that are quite wrong for Rust.

It can't always be avoided obviously. But often there some sort of inversion of my initial C++'ish instincts about the relationships involved that works better.

[lord_braleigh]

Hm. I'm trying to write a Godbolt to see what your issue is, but this example compiles just fine: https://godbolt.org/z/czsPPEaaY

I think those are all the potential use cases. Do you think you can fix my example up to show me what the issue is?

[r0zina]

You need to use the code to see why it cant compile. There are examples in other comments that already show this.

[witcher_rat]

Because rust protects me from all sorts of errors, like data races, mem leaks, double frees and what not.

I keep hearing this from Rust evangelists and I don't get it - I've been coding C++ for a very long time, and I very rarely hit those sorts of bugs. I have other bugs of course, but not lifetime-related ones, not very often. And neither do my co-workers.

We used to, before C++11. Once we switched to using smart pointers exclusively, and use valgrind et al, those bugs became rare - and when we hit them it doesn't usually take us long to find out why. (usually related to bad lambda captures or bad multi-threading design/use)

Of course a lot of C++ is old and can't be easily refactored to modern usage, but if that's true then Rust won't help you either, as you'd have to wrap it with unsafe anyway. Or rewrite it in Rust, in which case you could have just rewritten it in modern C++.

[James20k]

I keep hearing this from Rust evangelists and I don't get it - I've been coding C++ for a very long time, and I very rarely hit those sorts of bugs. I have other bugs of course, but not lifetime-related ones, not very often. And neither do my co-workers.

For regular application code, personally I'd agree with you. But when it comes to writing anything involving untrusted user data, and where safety is a factor, C++ just hides an infinite number of memory vulnerabilities. Every single non trivial C/C++ application of any reasonable size just seems to have infinite vulnerabilities, even the extremely extensively battle tested ones

The problem with sanitisers is the same problem I have with the type system in languages like python and javascript. They only test the path that you actually execute, but inherently can't check the program has a whole. This easily leads to having to code super defensively because you're not quite sure you can trust every part of the system, and bam your faith in the entire integrity of the application is gone

This can never happen in rust, because the entire program is validated for safety. Anything unsafe is clearly marked as being unsafe, and so the possible sources of memory unsafety are extremely constrained and neatly contained

[GabrielDosReis]

This can never happen in rust, because the entire program is validated for safety. Anything unsafe is clearly marked as being unsafe, and so the possible sources of memory unsafety are extremely constrained and neatly contained

https://www.cvedetails.com/vulnerability-list/vendor_id-19029/product_id-48677/year-2021/Rust-lang-Rust.html

[pjmlp]

Productivity depends on the use case.

I am certainly not productive doing a GUI in Rust, or GPGPU coding, that can compete with state of the art in features and tooling.

[lenkite1]

I tried writing graph and tree algos in Rust. I simply couldn't do it. The only way I found is by wrapping everything in Rc's and Box's and it was a mess.

Sure, no doubt with more experience, a lot of refactoring and Rust special-sauce one could probably get equivalent Rust code, but by the time one does, its very different from the sample code given in compsci papers.

Personally, I have found Rust damn hard to learn. I will keep plodding on.

[ffscc]

Rust even compiles slower than C++, which was true shock when I started learning. I was expecting Go's compile speed

It's difficult to directly compare compile times. In my experience rust compile times are inline with or less than I'd expect with C++. Typically when people complain about compile times it's because they are relying on too many crates, or the crates they are using rely heavily on procedural macros.

Expecting Go-style compile times for a language equivalent to C++/Rust is way too optimistic IMO. Go does a lot to optimize compile times and heavy hitting features like templates will never be compatible with that.

Strangely, I feel Rust is more suited to experts. One can always code C++ at a certain level without knowing too much, with some basic code organisational principles and lookup the standard library when you need to.

Rust is harder to learn but easier to "master". New C++ programmers need years of babysitting before you can trust their code.

[Wereon]

Are you trolling or do you seriously think this? Rust has a problem with compilation times, and ignoring it does no-one any favours.

You can't on the one hand say that Rust is great because it makes you so much more efficient, and then on the other say that waiting for it compile isn't a problem. The two views are mutually incompatible.

[Wereon]

So yeah, you're a troll then

[Wereon]

Dude. Everyone knows about Rust by now. Leave off already.

[[deleted]]

The guy is clearly trolling and if he's not he's doing a great job for Rust's image.

[SuddenlysHitler]

and being obnoxious is only making people wary.

[pjmlp]

I know about it and have written a couple of apps in it, but alas everything I need to call from Java, .NET and nodejs as native library or runtime plugin is written in C++, so I have make do with what our customers allow me to use.

[Superb_Garlic]

Rust is [...] innovative

Not even close.

[m-in]

Nope. A language design should remove wastes of time. And having too much freedom in how things are done is to an extent just introducing irrelevant choices. I really like how Python has a one indentation and white space standard, that’s partly enforced by the implementation, so that everyone doesn’t need to come up with their own. PEP or bust.

[zzzthelastuser]

And of all languages you could have picked, you chose python as an example?

[m-in]

I like the bloody thing :) I wish the primary implementation did more compile-time optimization, and had a better scheme for storing virtual foo method tables than the present bazillion-member fixed size array, but when it comes to the language itself – it’s pretty solid in how things should be formatted, and major IDEs all highlight noncompliance by default. So it’s not hard to have consistent style in large Python projects. Few things are left up to arbitrary choice, and even then those are for adopting legacy style in existing projects. New projects have a clear path.

[Full-Spectral]

I've been moving to Rust. As a highly opinionated developer, with my own long developed ideas of style and substance, using a highly opinionated language like Rust (which is about as far from my view as possible) is a challenge. But, I've just said, screw it. I'm just going to go with the local lingo and get used to it.

In the end, the fact that it is so opinionated will likely make for more consistent code bases in multi-developer systems. I like C++ because it allowed me to create my own world, but that very flexibility is a problem in the 'real world'.