Live data from Hacker News

Modern C++ Won't Save Us

alexgaynor.net

51–60 of 395 posts

Re: Modern C++ Won't Save Us

#51

Can someone at least make a linter that ensures you only use a "safe" subset of C++?

Clang's lifetime profile will catch the first example:

    :8:16: warning: passing a dangling pointer as argument [-Wlifetime]
      std::cout :7:38: note: temporary was destroyed at the end of the full expression
      std::string_view sv = s + "World\n";
                                         ^
And cppcheck will catch the second example:

    :7:12: warning: Returning lambda that captures local variable 'x' that will be invalid when returning. [returnDanglingLifetime]
        return [&]() { return *x; };
               ^
    :7:28: note: Lambda captures variable by reference here.
        return [&]() { return *x; };
                               ^
    :6:49: note: Variable created here.
    std::function f(std::shared_ptr x) {
                                                    ^
    :7:12: note: Returning lambda that captures local variable 'x' that will be invalid when returning.
        return [&]() { return *x; };
               ^
Cppcheck could probably catch all the examples, but it needs to be updated to understand the newer classes in C++.

Re: Modern C++ Won't Save Us

#52
post #14

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…

I don’t see how you can read TFA and describe it as “hate”. The author is showing real problems with C++; you could disagree with the severity of these problems or the solution presented, but calling this hate is so childish and dishonest.

Re: Modern C++ Won't Save Us

#53
post #14

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…

While there are obviously still cases where C++ makes sense to use today, those case are overwhelmingly based on the age and maturity of the C++ ecosystem. Now that Rust has proven that a language can provide memory safety without compromising (much) on performance, it is clear that the scope of C++'s supremacy is in permanent decline.

As Rust (or another language with similar safety/performance properties) matures and its ecosystem grows, C++ will increasingly become a language of tiny niches and legacy codebases.

In other words: C++ is the new Fortran.

Re: Modern C++ Won't Save Us

#54

Earlier quoted context omitted.

The irony is it's mostly unsafe if you test for the null, such that the compiler can omit a test, but if there's no evidence the pointer can be null you just get a normal memory access. The optimizer is not optimized for most intuitive behavior.

The null checks are only optimized away if you've already derefenced the pointer before the null check within a scope. Optimizer rationale being youve already derefenced it, so it must not be null, therefore the null check is unnecessary. Also, you can "safely" dereference nullptr, just so long as you dont attempt to actually access the memory. C++ references are nothing more than a fancy pointer with syntactic sugar…

UB isn't "safe" so I'm unsure what your comment is getting at

Re: Modern C++ Won't Save Us

#55
post #13
post #7

This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. These are added to the language to prevent memory allocation and data copy for performance critical software. Herb Sutter has concrete proposals to address this issue and Clang already supports them: https://www.infoworld.com/artic…

The thing is, Rust has tools that are easier to use _and_ have great performance _and_ prevent security and stability mistakes.

Does rust have a structure to handle something like a stringview?

Re: Modern C++ Won't Save Us

#56
post #15

Question - How does one write microcontroller code (or other memory-mapped I/O code) using a memory-safe language?

Tradeoffs.

Ada has a history on microcontrollers, and is old enough we can answer with some certainty.

You may end up having to bypass bottlenecks caused by runtime checks... And that means unsafe code in a critical location.

Performance or safety. At different parts of your code you may find yourself choosing.

Re: Modern C++ Won't Save Us

#57
post #22
post #15

Question - How does one write microcontroller code (or other memory-mapped I/O code) using a memory-safe language?

Historically speaking, you didn't. It is only relatively recently that microcontrollers have become powerful and spacious enough for that to be an option.

Depends what you mean by recent. Ada's been on microcontrollers for more than a couple decades.

Re: Modern C++ Won't Save Us

#58
post #53
post #14

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…

While there are obviously still cases where C++ makes sense to use today, those case are overwhelmingly based on the age and maturity of the C++ ecosystem. Now that Rust has proven that a language can provide memory safety without compromising (much) on performance, it is clear that the scope of C++'s supremacy is in permanent decline. As Rust (or another language with similar safety/performance properties) matures a…

> In other words: C++ is the new Fortran.

Which makes Rust the new... APL?

I think the analogy is pretty apt as far as it goes. Fortran by the 70's was a crufty language with a bunch of legacy mistakes that remained very popular and very useful and would continue to see active use for decades to come.

And everyone knew that. And everyone had their own idea about the great new language that was "clearly" going to replace Fortran. And pretty much everyone was wrong. The language that did (C) was one no one saw coming and frankly one that didn't even try to fix a lot of the stuff that everyone was sure was broken.

For myself, I despair that Rust has already jumped the proverbial shark. It's complexity is just too severe, the only people who really love Rust are the people writing Rust libraries and toolchains, and not the workaday hackers who are needed to turn it into a truly successful platform.

Re: Modern C++ Won't Save Us

#59
The stringview example is surprising and certainly something I could have fallen for.

I feel like the lambda example is pretty contrived. If I was returning a lambda that was capturing values by reference, I would already be pretty wary of UB.

Re: Modern C++ Won't Save Us

#60
post #30
post #14

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…

Qt has Rust bindings now. I hope CUDA will get replaced with proper cross GPU alternatives anyway. Rust GPU programming should be also possible.

Rust gpu programming is very possible already, but as of my most recent foray into the area it was still very much a black art getting your build environment set up for it. It’s probably just a matter of time before it becomes an easy thing to do.

I’ve done a fair bit of mixed Rust + CUDA C++ though, and found it to be a very nice way to build high performance code with safe high-level interfaces that someone can grab and use with little to no understanding of GPU architectures. It’s even pretty straightforward to build wrapper types that leverage Rust’s ownership system to track lifetimes and safe management of device buffers as well (unfortunately I can’t release that code but it really was pretty simple so hopefully someone else will soon do it openly, or by now maybe someone already has)

Post reply on HN