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

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

121–130 of 395 posts

Re: Modern C++ Won't Save Us

#121

Post by kccqzy »

raphlinus wrote: post #10

From the article: > Dereferencing a nullptr gives a segfault (which is not a security issue, except in older kernels). I know a lot of people make that assumption, and compilers used to work that way pretty reliably, but I'm pretty confident it's not true. With undefined behavior, anything is possible.

Absolutely. In many experience if clang can deduce a function will definitely trigger UB such as definitely dereferencing a null pointer, it generally optimizes the entire function after the reference into a single ud2 instruction. (Which raises the #UD exception in the CPU).

This is something really hardwired into the C and C++ language. Even if the underlying operating system perfectly supports dereferencing null pointers, compilers will always treat them as undefined behavior. (In Linux root can mmap a page of memory at address 0, and certain linker options can cause the linker to place the text section starting at address 0 as well.)

Re: Modern C++ Won't Save Us

#122

Post by ncmncm »

sys_64738 wrote: post #9

Today's C++ will be considered a cobbled together relic in a few C++ standards time periods!

By then Rust will also seem a cobbled-together relic, and you will be chasing the new hotness. In the meantime, we are writing the code that makes the world work. In C++.

By then, many will also be writing it in Rust, and you will be sneering at them, too. It has always bern easy to sneer at people busy making things work.

Re: Modern C++ Won't Save Us

#123

Post by AnimalMuppet »

raphlinus wrote: post #83
mjevans wrote: post #65

Earlier quoted context omitted.

My opinion on that, is that such code MUST NOT be optimized away. Instead it should be a compile error.

You might wish for that, but the ship has sailed. Undefined behavior means that the implementation can do whatever it can. That said, I do expect tools, both sanitizers and static analyzers to improve to detect more of these kinds of cases.

There have been static analyzers that will detect this for years. They report "check for null after use" or some such.

Re: Modern C++ Won't Save Us

#124

Post by jclay »

shmerl wrote: post #30
jclay wrote: 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.

The issue with bindings is that you either commit to maintaining them yourself, or you rely on someone else. In this case, the Rust Qt bindings I found [0] were generated for Qt 5.8, which was released nearly 3 years ago. The tests on Github report "failing".

Then, you have the cognitive overhead of translating the documentation, and other sample code. In my experience with bindings, this ends up requiring knowledge of the language you're binding to. It seems easier to just write it in the native language instead and deal with those quirks rather than bindings quirks.

Do the Rust bindings show the Qt docs in the autocomplete? If there's not input validation on the binding side, then you'll end up in C++ again figuring out how to sort things out.

Regarding CUDA, I think we're all hoping for a cross GPU alternative. There's OpenCL, Sycl, ROCm, Kokkos but their API is also written in (you guessed it) C++. Need to render to OpenGL? You'll be writing in C. Unless one of the companies decides to replace driver interfaces with Rust, any application using them will be dependent on N bindings working.

You're ultimately not escaping C/C++ for any systems development. You either deal with the complexity of interfacing between language A and C/C++ or just deal with the quirks of C/C++ themselves. Pick your poison.

0. https://github.com/rust-qt/ritual

Re: Modern C++ Won't Save Us

#125

Post by ncmncm »

nradov wrote: post #108
fooker wrote: post #103

Earlier quoted context omitted.

I don't see the problem. You are free to use such a modern library (Google does, it's called absl). The good thing here is that the standard library doesn't require 'magic' to be implemented (unlike Swift where the standard library relies on hidden language hacks).

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

The whole point of C++ is that it enables writing more powerful libraries, capturing semantics in libraries that can then just be used. C++ is still quite a lot more powerful for this purpose than Rust. Rust will get better at it, over time, but it has a long way to go and C++ is not siiting still.

Rust is still a niche language, and if its rates of adoption and improvement do not keep up, it will remain a niche language, and fade away like Ada.

I cannot imagine a serious programmer switching from C++ to Go. If you can, you have a much livelier imaginary life than I do.

Re: Modern C++ Won't Save Us

#126

Post by shmerl »

jclay wrote: post #124
shmerl wrote: post #30

Earlier quoted context omitted.

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

The issue with bindings is that you either commit to maintaining them yourself, or you rely on someone else. In this case, the Rust Qt bindings I found [0] were generated for Qt 5.8, which was released nearly 3 years ago. The tests on Github report "failing". Then, you have the cognitive overhead of translating the documentation, and other sample code. In my experience with bindings, this ends up requiring knowledge…

There were multiple attempts at such bindings. The most promising is this one:

https://github.com/KDE/rust-qt-binding-generator

> You're ultimately not escaping C/C++ for any systems development.

We eventually should. C/C++ should retire even for drivers and kernels. But for now there is still a lot of baggage to deal with indeed.

Re: Modern C++ Won't Save Us

#127

Post by blt »

millstone wrote: post #98
jandrewrogers wrote: post #71

A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more an…

I agree with this and would take it a step further, and say that recent changes to the STL are the worst parts of modern C++. For example std::regex supports 6 distinct syntaxes, the PRNG stuff is massively over-engineered, the "extensions for parallelism" add complexity without giving enough knobs for any real perf improvement. Meanwhile there's gaping holes like UTF-8 support. It's a sad state.

How is the prng over engineered? I agree its a little clunky for casual use but it makes all the right decisions, imo, for serious use of prngs (e.g. reproducible experiments for Monte Carlo methods in simulation and statistics)

Re: Modern C++ Won't Save Us

#128

Post by ncmncm »

Inityx wrote: post #74
ajross wrote: post #64

Earlier quoted context omitted.

> It’s definitely easier to reason about than C++ See... I don't think that's true, and argue the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary. I mean, sure, C++ has its crazy edge cases and its odd notions. But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code. Literally hundreds of tho…

> the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary Looks to me more like proof that C++ has been around a long time

Lots of languages have been around a long time without attracting billions of lines of code. To get that, the language must be unusually useful.

Re: Modern C++ Won't Save Us

#129

Post by AnimalMuppet »

mlindner wrote: post #79
0815test wrote: post #24

Earlier quoted context omitted.

Yes, AIUI Swift does not ensure memory safety for concurrent code like Rust does. You have to expressly opt-in to concurrency-safety, and it's not checked by the compiler. Go definitely has this issue, which is admittedly bizarre for a language that's so often used to code network-oriented services making heavy use of concurrency.

I find anyone using Go for networking code bizarre. It's bizarre to me the language ever caught on especially because all their design goals are explicitly the wrong goals. Their goal was to make a "simple like C" language which simply disguises the complexity in writing software. Go simply punts complexity to technical debt of any project and assumes you will throw out your code after a year of using it.

You are very much wrong, on several fronts.

First, you obviously have some measuring stick for what the "right" language design goals should be. But what you don't seem to recognize is that other people can validly have other design goals. It's not "your way or they're wrong".

In fact, given the decades of experience the designers of go have (and wide variety of languages that they have experience with), it's almost certain that you know far less than they do. And yet they still made different choices than you would. Instead of wondering how they could be so stupid, that should make you wonder what they knew that you don't.

(I've seen some rants from people saying stuff like "they couldn't have made that design decision if they knew anything about Modula 2!" And they miss the talk by Rob Pike where he said (paraphrased) "don't think we're so smart for coming up with that object file format - we stole it from Modula 2". They knew it at a very deep level - almost certainly better than their critic did.)

Then there's this:

> Go simply punts complexity to technical debt of any project and assumes you will throw out your code after a year of using it.

Go was designed for multi-million line code bases that live for decades. Really. Read Rob Pike's notes on Go's design.

So, yeah, there's a lot about this rant that is factually off in the weeds...

Re: Modern C++ Won't Save Us

#130

Post by vasilipupkin »

Tracist wrote: post #116
ncmncm wrote: post #114

Earlier quoted context omitted.

There is no such language as C/C++. There is C, which cannot be written safely, and there is C++, which can be, and quite often is. It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. I am constantly dealing with design, specification, and logic flaws, which affect Rust equally, or moreso. I am aware that there are plenty of other programmers out there, writing bad code in…

> It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. The whole comment sounds so much like well written satire, but I think he's being serious.

I agree with him. in many practical applications with well design class hierarchies it just really isn't much of an issue. Hasn't been for me either.
Post reply on HN