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

361–370 of 395 posts

Re: Modern C++ Won't Save Us

#361

Post by cpeterso »

aliceryhl wrote: post #325
maccard wrote: post #301

Earlier quoted context omitted.

You can also do it in a one-liner in C++ if you're using shared pointers: if(auto obj = my_weak_ptr.lock()) { do_stuff(obj); } > Having to pay for a check is "paying for what you use". If you don't like it then don't make the object nullable in the first place and save yourself the test. The point is that I can choose _when_ to pay that cost (e.g. I can eat the nullability check at this point, but not at this point,…

The rust code in question is not using reference counting.

Rust's borrow checker is like compile-time reference counting. Same benefit, but no run-time cost.

Re: Modern C++ Won't Save Us

#362

Post by int_19h »

blub wrote: post #356
int_19h wrote: post #351

Earlier quoted context omitted.

Rust is the only serious attempt to fix those negatives while remaining in the same niche, so bringing it up in this context is natural. And C++ can't really truly fix them without breaking backwards compatibility with all the legacy C++ and C code, which is its main selling point.

It's the only "serious" attempt as declared by whom exactly, the committee of serious attempts? There are other serious attempts (D, Swift, Go) which the Rust community likes to dismiss for various reasons, but at least two of them are currently much more successful than Rust. They don't have to be 100% in the same niche to take a bite of marketshare. Even if C++ breaks backwards compatibility in some ways, it will s…

I do not dispute that the languages that you've listed are serious attempts. They do not remain in the same niche, however. I would define that niche as "capable of replacing C even in free-standing implementation".

For D and Go, having a GC immediately puts them outside of that niche. For Go, I would also add all the FFI weirdness due to its weird stack discipline, which means that it is non-zero-overhead when interacting with non-Go code - a fatal omission for any contender for a low-level systems language.

Swift is much closer to the metal, and I would consider it a serious contender if it was pushed on all platforms. But it seems that Apple is not interested in its use outside of their ecosystem, which constrains its effective niche to be much narrower than C++ or Rust, ironically.

And yes, of course C++ is always going to have better backwards compatibility. If it didn't, it wouldn't be C++. But its ability to fix issues is directly correlated with that compatibility - it's a dial where you can have more of one and less of the other, as you choose, but you can't have both. Rust (and Swift) can fix more problems, or can fix problems in better ways, because they are not so constrained.

Conversely, if C++ were to introduce safe-by-default, and require explicit opt-in into unsafe - with all present code being considered unsafe - then what you have is a new language that just happens to embed C++ for compatibility reasons. At that point you might as well fix the syntax warts etc as well in that new safe language, since it breaks everything anyway.

Re: Modern C++ Won't Save Us

#363

Post by ncmncm »

_bxg1 wrote: post #335
ncmncm wrote: post #332

Earlier quoted context omitted.

This is not about "expressive freedom" vs "constraints". Rust lacks many of C++'s key core language facilities to capture semantics in a library. As a consequence, you cannot write powerful libraries in Rust that you can in C++, and you cannot use powerful libraries such as are written in C++. Since you cannot use these powerful libraries, you are (if you like) "constrained" to write fragile code at what would have b…

"Rust lacks many of C++'s key core language facilities to capture semantics in a library." Can you be more specific? I don't even know what you mean by "powerful library". If you mean a library that's been developed and debugged for a long time, then sure, C++ currently has the advantage there, but that's a transient state and nonspecific to the language itself. If you mean a library that does wild, earth-moving thin…

Could you write a Rust equivalent of the STL, or its modern cousin Ranges? That's just one library (as of C++20), but if Rust is not up to that, there's no point in going further.

Re: Modern C++ Won't Save Us

#364

Post by ncmncm »

comex wrote: post #234
tpolzer wrote: post #178

Earlier quoted context omitted.

Chrome is in an exceptionally hard place because of its JIT. Your language cannot tell you if it's safe for your JIT to omit a bounds check.

That post describes two vulnerabilities: one is in the JIT, but the other one is in regular old C++ code. More generally, JIT bugs are a relatively small minority of browser vulnerabilities. More often you see issues like use-after-free in C++ code that interacts with JS, such as implementations of DOM interfaces, but the issues are not directly JIT related and would be avoided in a fully memory-safe language.

Chrome, like Firefox, is not an example of modern C++ code. Google's and Mozilla's coding standards enforce a late-'90s style. It is astonishing they get it to work at all.

Re: Modern C++ Won't Save Us

#365

Post by steveklabnik »

ncmncm wrote: post #363
_bxg1 wrote: post #335

Earlier quoted context omitted.

"Rust lacks many of C++'s key core language facilities to capture semantics in a library." Can you be more specific? I don't even know what you mean by "powerful library". If you mean a library that's been developed and debugged for a long time, then sure, C++ currently has the advantage there, but that's a transient state and nonspecific to the language itself. If you mean a library that does wild, earth-moving thin…

Could you write a Rust equivalent of the STL, or its modern cousin Ranges? That's just one library (as of C++20), but if Rust is not up to that, there's no point in going further.

The equivalent of Ranges is already in Rust’s standard library, and has been forever. We call it Iterator. It also provides extra static guarantees against invalidation.

Re: Modern C++ Won't Save Us

#366

Post by leetcrew »

majewsky wrote: post #359
eska wrote: post #302

Earlier quoted context omitted.

You're misrepresenting the report in order to justify your bias. Direct quote from the report: This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behi…

Readable version of the quote: > This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behind major infrastructure like Open SSL and the Linux kernel. Th…

> unless you hate mobile users

or just period. I'm reading this on a 4K desktop display, and I still have to scroll. it's only useful for actual code, which is very rarely posted on hn.

Re: Modern C++ Won't Save Us

#367

Post by paulmooreparks »

dodobirdlord wrote: post #170
paulmooreparks wrote: post #134

Earlier quoted context omitted.

Why is it difficult to believe? I've also written plenty of C++ code without memory bugs. It's not that hard if you play by a few simple rules.

> I've also written plenty of C++ code without memory bugs. The classic response to this is "That you know of." Consider that even quality-conscious projects with careful code review like Chrome have issues like this use-after-free bug from time to time. https://googleprojectzero.blogspot.com/2019/04/virtually-unl... So when people claim that they personally don't write memory bugs I tend to assume that they are mist…

In this case, I mean a subsystem that has been in production since 2006 and has been processing hundreds of thousands of messages a day. I don't claim that it's perfect or bug-free, but if it had significant memory errors I'd have heard about it. I designed and implemented it to use patterns like RAII to manage memory, and it's worked quite well.

Re: Modern C++ Won't Save Us

#368

Post by paulmooreparks »

gmueckl wrote: post #274
sgift wrote: post #251

Earlier quoted context omitted.

> Writing memory safe programs in C++ is possible. Everything "is possible" in the sense that in theory you can do it. But if time and time again people fail to do it. Even people who invest almost heroic levels of effort (see above: valgrind, multiple sanitizers, and so on) you get to the point where you have to accept that what is possible in theory doesn't work in practice.

I have seen it done in practice, on rather large systems. But it requires actual, slow software engineering instead of the freestyle coding processes that are used in most places.

My main rule is "no naked new," meaning that the only place the new operator is allowed is in a constructor, and the only place delete is allowed is in a destructor (unless there's some very special circumstance). This style lends itself to RAII. The other rule is to use the standard library containers unless there's a very good reason not to do so. That seems to cover most of the really basic errors.

Re: Modern C++ Won't Save Us

#369

Post by ncmncm »

steveklabnik wrote: post #365
ncmncm wrote: post #363

Earlier quoted context omitted.

Could you write a Rust equivalent of the STL, or its modern cousin Ranges? That's just one library (as of C++20), but if Rust is not up to that, there's no point in going further.

The equivalent of Ranges is already in Rust’s standard library, and has been forever. We call it Iterator. It also provides extra static guarantees against invalidation.

I see that you did not understand my question.

I see, too, that there are plans for some support for generics in the near future. So the answer might become yes, in time.

Re: Modern C++ Won't Save Us

#370

Post by ncmncm »

int_19h wrote: post #353
ncmncm wrote: post #332

Earlier quoted context omitted.

This is not about "expressive freedom" vs "constraints". Rust lacks many of C++'s key core language facilities to capture semantics in a library. As a consequence, you cannot write powerful libraries in Rust that you can in C++, and you cannot use powerful libraries such as are written in C++. Since you cannot use these powerful libraries, you are (if you like) "constrained" to write fragile code at what would have b…

Can you give an example of said "key core language facilities" that make some library implementable in C++, but not Rust? I can give an example of the opposite: language-aware macros. No amount of C++ TMP hackery can approach a well-designed Rust DSL.

Rust macros understand types now? Woohoo!
Post reply on HN