| ▲ | bagxrvxpepzn 14 hours ago |
| To the people who work on C++ standards: I approve of the current C++ trajectory and please ignore all of the online noise about "the future of C++." To anyone that disagrees severely with the C++ trajectory as stated, please just consider another language, e.g. Rust. I don't want static lifetime checking in C++ and if you want static lifetime checking, please use Rust. I am not a government contractor, if you are a government contractor who must meet bureaucratic risk-averse government requirements, please use Rust. I have an existing development process that works for me and my customers, I have no significant demand for lifetime checking. If your development process is shiny and new and necessitates lifetime checking, then please use Rust. To Rust advocates, you can have the US government and big tech. You can even have Linux. Just leave my existing C++ process alone. It works and the trade offs we have chosen efficiently accomplish our goals. |
|
| ▲ | bluGill 10 minutes ago | parent | next [-] |
| C++ is on the trajectory to create a future with more safety. Should we do profiles or static lifetime checking (or something else??) is still an open question (and both may be valid). However I'm glad c++ is thinking about that. We have real problems around safety in the real world and people are writing unsafe code even when modern safe code would be easier to write. Of course it remains to be seen how this all plays out. Static lifetimes can be done good or bad. Profiles can be good or bad. Even if whatever we come up with is done well that doesn't mean people will (I know rust programmers who just put unsafe everywhere). |
| |
| ▲ | zozbot234 4 minutes ago | parent [-] | | Profiles are vaporware. The C++ folks are pushing a fantasy of "full memory safety with no changes to existing code, not even annotations to enable static analysis." That's just a non-starter, there is no way to get to full memory safety from there unless you count very silly things like making "delete" and "free()" a no-op - and also running everything in a single thread for "concurrency safety". |
|
|
| ▲ | AlotOfReading 14 hours ago | parent | prev | next [-] |
| C++ has lifetime rules just like Rust. They're simply implicit in the code and not enforced by the compiler. Do you prefer the uncertainty of silent miscompilations and undefined behavior to upfront compiler errors? You're already using a language with a strong type system, so it's confusing to me why you would choose to draw the line here. |
| |
| ▲ | bagxrvxpepzn 13 hours ago | parent | next [-] | | > Do you prefer the uncertainty of silent miscompilations and undefined behavior to upfront compiler errors? Yes because then I don't have to spend hours writing esoteric spaghetti code to prove something to the compiler that is trivially known to be true. Your error is assuming static lifetime checking is free. As an engineer, I use judgement to make context-dependent trade offs. If you like playing the compiler olympics, or your employer forces you to, please use Rust. | | |
| ▲ | roland35 13 hours ago | parent | next [-] | | I've found that often when I am writing esoteric spaghetti rust code... I need to start thinking about what I am trying too do! Most of the time it's a bad idea :) | |
| ▲ | 13 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | rramadass 9 hours ago | parent | prev | next [-] | | > As an engineer, I use judgement to make context-dependent trade offs. Well said. This is why i am firmly in the Stroustrup camp of backward compatibility/zero overhead/better-C/etc. goodness of "old C++". I need to extend/maintain/rewrite tons of them and that needs to be as painless as possible. The current standards trajectory needs to be maintained. The OP article is a rather poor one with no insights but mere hoopla over nothing. | |
| ▲ | th2oi34234234 2 hours ago | parent | prev [-] | | LOL; someone has definitely played with type-systems here. |
| |
| ▲ | lelanthran 2 hours ago | parent | prev | next [-] | | > C++ has lifetime rules just like Rust. They're simply implicit in the code and not enforced by the compiler. The problem is that the rules enforced by Rust is not restricted to lifetime rules, it's a much much larger superset that includes quite a lot of safe, legitimate and valid code. | | |
| ▲ | AlotOfReading 23 minutes ago | parent | next [-] | | Sure, but that's not a design philosophy C++ adheres to. Look at the modern C++ guidelines or profiles. The entire point is to rule out large swathes of safe, legitimate, and valid code in an optional and interoperable way. C++ isn't beholden to Rust's trade-offs either. There's a whole spectrum of possibilities that don't require broken backwards compatibility. Hence:
"Why draw the line specifically at lifetime annotations?" | |
| ▲ | PittleyDunkin an hour ago | parent | prev [-] | | That's what the unsafe keyword is for. |
| |
| ▲ | guappa 3 hours ago | parent | prev [-] | | > You're already using a language with a strong type system I'll have you know I made a variable void* just yesterday, to make my compiler shut up about the incorrect type :D |
|
|
| ▲ | sumanthvepa 4 hours ago | parent | prev | next [-] |
| Thank you for this. C++ should NOT try to be Rust. I find modern C++ really nice to program in, for the work I'm doing - 3D graphics. The combination of very powerful abstractions and excellent performance is what I'm looking for. I'm more than willing to endure percived lack of safety in the language. |
|
| ▲ | GrantMoyer 11 hours ago | parent | prev | next [-] |
| While programming in Rust, I've never thought to myself, "man, this would be so much easier to express in C++". I've plenty of times thought the reverse while programming in C++ though. Edit: except when interfacing with C APIs. |
| |
| ▲ | kkert 9 hours ago | parent | next [-] | | This is interesting because i'm writing quite a bit of embedded Rust, and i always run into limitations of very barebones const generics. I always wish they'd have half the expressiveness of C++ constexpr and templates. Win some, lose some though, as the overall development workflow is lightyears ahead of C++, mostly due to tooling | | |
| ▲ | badmintonbaseba 5 hours ago | parent | next [-] | | The expressiveness of const generics (NTTPs) in C++ wouldn't go away if it adopted lifetime annotations and "safe" scopes. It's entirely orthogonal. Rust decided to have more restrictive generic programming, with the benefit of early diagnostic of mistakes in generic code. C++ defers that detection to instantiation, which allows the generics to be more expressive, but it's a tradeoff. But this is an entirely different design decision to lifetime tracking. | |
| ▲ | zozbot234 4 hours ago | parent | prev | next [-] | | Rust generics are not intended as a one-to-one replacement for C++ templates. Most complex cases of template-level programming would be addressed with macros (possibly proc macros) in Rust. | | |
| ▲ | galangalalgol an hour ago | parent [-] | | Const generic expressions are still being worked. They are what is blocking portable simd. They are also a much cleaner way to implement things like matrix operations or really anything where a function with two or more arguments of one or more types returns things that have types that are a combination or modification of the input types. | | |
| ▲ | zozbot234 17 minutes ago | parent [-] | | The problem AIUI is that "const generic expressions" in full generality are as powerful as dependent types. It's not clear to me that the Rust folks will want to open that particular can of worms. |
|
| |
| ▲ | afdbcreid 8 hours ago | parent | prev [-] | | That's actually quite interesting because this is not an inherent limitation of Rust, and it is definitely planned to be improved. And AFAIK, today (as opposed to last years) it is even being actively worked on! |
| |
| ▲ | bowsamic 4 hours ago | parent | prev [-] | | Then you must be avoiding situations that traditionally use OOP | | |
| ▲ | zozbot234 3 hours ago | parent [-] | | Most kinds of OOP can be expressed idiomatically in Rust. The big exception is implementation inheritance, which is highly discouraged in modern code anyway due to its complex and unintuitive semantics. (Specifically, its reliance on "open recursion", and the related "fragile base class" problem) | | |
| ▲ | galangalalgol 40 minutes ago | parent [-] | | People often say that modern c++ doesn't have the problems needing a solution like rust. Ironically that means people who write modern c++ haven't had any aramp up time needed when joining our rust projects. They were already doing things the right way. At least mostly. But now they don't have to worry about that one person who seems to be trying to trick the static analysis tools on purpose. |
|
|
|
|
| ▲ | Attrecomet 5 hours ago | parent | prev | next [-] |
| What I don't understand is why you demand that C++ evolution be halted in a clearly suboptimal position so you don't need to change your processes. Just use the version of C++ that meets your needs, you clearly don't want nor need new developments. You are fine with being locked into bad designs for hash maps and unique ptr due to the (newly invented, in 2011/13) ABI stability being made inviolable, you clearly need no new developments in usability and security. So why not be honest and just use C++01, or 11, or whatever it is that works for you, and let the rest of the ecosystem actually evolve and keep the language we invested so much effort into as a viable alternative? There's zero benefit, except to MS who want to sell this year's Visual Studio to all the companies with 80's-era C++... |
| |
| ▲ | liontwist 2 hours ago | parent [-] | | > evolution be halted in a clearly suboptimal position It’s clear it’s imperfect. But not clear there is an obvious path to a nearby local maxima. Design choices have tradeoffs. And even if that were true, who would take advantage of that “better” language in a purely abstract sense? New language standards primarily exist to benefit existing C++ code bases, and the cohort of engineers who work on them. You have to consider that social reality. |
|
|
| ▲ | feelamee 12 hours ago | parent | prev | next [-] |
| Ok.
Please, just use your current C++ standard.
But we will go to use the new one with all features we want to use. |
|
| ▲ | diath 14 hours ago | parent | prev | next [-] |
| On the contrary, why would I not want these things in C++ if I'm developing every project with -fsanitize=address,undefined to catch these types of errors anyway? |
|
| ▲ | chlorion 2 hours ago | parent | prev | next [-] |
| Imagine an engineer in any other field acting like this. "I don't want to install air bags and these shiny safety gadgets into my cars. We have been shipping cars without them for years and it works for us and our customers." The problem is that it doesn't actually work as well as you think, and you are putting people at risk without realizing it. |
| |
| ▲ | downut an hour ago | parent [-] | | You are making a general statement about the distribution of general consumers of computer languages, complete with a long tail, and the commenter is explaining that he is an expert car driver, way out there on the long tail. This tyranny of the less capable mode is really grating, especially on a site named "Hacker News". As usual, the answer is quite simple: "please use rust". We promise to never mention when we break out nasm. Driver anecdote: I have antilock brakes on my Tundra, but they are annoyingly counterproductive in 4WD descending 6" or larger sandy rocky steps. Do antilock brakes work overall best for the less capable mode? Of course! Do they work best for me? No. | | |
| ▲ | ModernMech 17 minutes ago | parent [-] | | We learned a long time ago as an industry that the expert car drivers are not immune to causing pile ups, which makes it all our problem to solve. Safety by default with escape hatches when absolutely necessary is the better way to go for all, even if it means some power users have to change their ways. |
|
|
|
| ▲ | 616c 14 hours ago | parent | prev | next [-] |
| [flagged] |
| |
| ▲ | umanwizard 9 hours ago | parent | next [-] | | Please don't shame people for using pseudonyms on here, regardless of whether you disagree with their concrete point. It's nice to have a place where people don't have to think about how their friends, family or colleagues will react before posting something. | |
| ▲ | AnimalMuppet 13 hours ago | parent | prev [-] | | > But why say so under a pseudonym That's a rather odd complaint, coming from a pseudonym. |
|
|
| ▲ | jandrewrogers 13 hours ago | parent | prev [-] |
| The parts of the government that think everything should be written in a memory-safe language (like Rust) are the same parts that already write everything in Java. Most of the high-end systems work is in C++, and that is the type of software where lifetimes and ownership are frequently unknowable at compile-time, obviating Rust's main selling point. |
| |
| ▲ | AlotOfReading 12 hours ago | parent [-] | | It's not a hard dichotomy. Almost all of the rules Rust imposes are also present in C++, enforcement is simply left up to the fallible human programmer. Frankly though, is it that big a deal whether we call it unique_ptr/shared_ptr or Box/Arc if a lifetime is truly unknowable? Rust shines in the other 95% of code. I spend some time every morning cleaning up the sorts of issues Rust prevents that my coworkers have managed to commit despite tooling safeguards. I try for 3 a day, the list is growing, and I don't have to dig deep to find them. My coworkers aren't stupid people, they're intelligent people making simple mistakes because they aren't computers. It won't matter how often I tell them "you made X mistake on Y line, which violates Z rule" because the issue is not their knowledge, it's the inherent inability of humans to follow onerous technical rules without mistakes. |
|