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

331–340 of 395 posts

Re: Modern C++ Won't Save Us

#331

Post by GoblinSlayer »

madisfun wrote: post #215
petters wrote: post #145

Earlier quoted context omitted.

Initializing the mersenne twister is really hard: https://github.com/PetterS/monolith/blob/master/minimum/core... Edit: There are two links in the code with more info.

Mersenne Twister has a huge state, and if you have to use the MT (you need a very long period), you will probably want to be able to initialize it properly. For the common use case is a linear congruential generator which is initialized with just one integer.

Huh? You can't possibly need a period 2^19937-1.

Re: Modern C++ Won't Save Us

#332

Post by ncmncm »

_bxg1 wrote: post #136
ncmncm wrote: post #117

Earlier quoted context omitted.

That doesn't make C++ a good language. It just is one. Rust is also a good language. Trash-talking C++ does no one any good. Overwhelmingly, the substantial gains to be made are moving people off of C. Every other possible benefit is a rounding error. It is still much easier to get people to C++. Once dislodged, they might continue on to Rust, or br seduced by C++'s greater expressive power and more powerful librarie…

"or be seduced by C++'s greater expressive power" There's a deeper debate lying at the heart of the Rust-vs-C++ conversation (it's the same one at the heart of Haskell-vs-Lisp), which is really about expressive freedom vs. the strategic usage of constraints. That debate will, truly, outlive all of us. You can probably guess which side I'm biased towards; I won't lay it all out here.

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 been the call site.

Each use of a powerful library eliminates all the bugs that would have come from not using one. Those are bugs that Rust designers have elected to keep, in exchange for the memory-use bugs that we largely eliminate, in C++ code, by reliance on powerful libraries.

Powerful libraries eliminate many, many more bugs besides memory misuse.

Re: Modern C++ Won't Save Us

#333

Post by ncmncm »

lmm wrote: post #328
ncmncm wrote: post #322

Earlier quoted context omitted.

>Can you write down the algorithm that you use to avoid writing memory bugs? Can you teach others how to do it? Yes. Code using powerful libraries. Every use of a powerful library eliminates any number of every kind of bug. Rust has not caught up to C++'s ability to code powerful libraries, and might never. C++ is a moving target. C++20 is more powerful than C++17, which was more powerful than 14, 11, 03. There are c…

> Yes. Code using powerful libraries. Every use of a powerful library eliminates any number of every kind of bug. So if I find that a C++ project is using powerful libraries, I can be confident that it doesn't have memory errors? History suggests not.

If I find a Rust program that is (perforce) not using powerful libraries, can I be confident that it does not harbor grave errors?

Certainly not. Rust takes aim at memory errors, and misses the rest that would be avoided by encapsulating bug-prone code in libraries. C++ enables capturing bug-prone code in well-tested libraries, eliminating whole families of bugs, including, in my recent experience, memory bugs.

That is not to say all C++ code is bug-free. Google and Mozilla code, by corporate fiat, is forbidden to participate.

Re: Modern C++ Won't Save Us

#334

Post by AnimalMuppet »

kevin_thibedeau wrote: post #290
AnimalMuppet wrote: post #82

Earlier quoted context omitted.

Most of the ones of those I am familiar with had 0 as a non-writable address, so you'd still crash. [Edit: Though that's probably hardware specific, and the hardware was usually custom.] It might be called "bus error" or some such instead of "segfault", but it was pretty much the same behavior.

Plenty of microcontrollers have a vector table at address 0. Best place to start injecting code.

Sure. The 68000 series did. But address 0 held the starting program counter, and address 4 held the starting stack pointer (or vice versa - it's been a while). Those two were usually mapped to ROM, because they had to have the right values even on cold boot. But that also meant that they weren't writable. So if you had a null pointer, you could read through it, but an attempt to write through it would give you a bus error.

Re: Modern C++ Won't Save Us

#335

Post by _bxg1 »

ncmncm wrote: post #332
_bxg1 wrote: post #136

Earlier quoted context omitted.

"or be seduced by C++'s greater expressive power" There's a deeper debate lying at the heart of the Rust-vs-C++ conversation (it's the same one at the heart of Haskell-vs-Lisp), which is really about expressive freedom vs. the strategic usage of constraints. That debate will, truly, outlive all of us. You can probably guess which side I'm biased towards; I won't lay it all out here.

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 things then I would call that a liability, not an advantage. The language features that allow such things are sources of bugs that Rust designers have elected not to introduce in the first place.

The question of, "In April 2019, which language and ecosystem are more reliable?" is a perfectly valid one. Stronger language semantics vs decades of library refinement. It's not at all obvious. But the answer to "Is Rust or C++ a better language in the long run?" seems clear to me.

Re: Modern C++ Won't Save Us

#336

Post by ncmncm »

rcxdude wrote: post #299
ncmncm wrote: post #139

Earlier quoted context omitted.

It is a legitimate C killer. C++, not so much.

people who liked C (and didn't like C++) are more likely to move to go. Rust has a healthy community of ex and current C++ programmers.

People who don't like GC will not move to Go.

Re: Modern C++ Won't Save Us

#337

Post by lmm »

ncmncm wrote: post #333
lmm wrote: post #328

Earlier quoted context omitted.

> Yes. Code using powerful libraries. Every use of a powerful library eliminates any number of every kind of bug. So if I find that a C++ project is using powerful libraries, I can be confident that it doesn't have memory errors? History suggests not.

If I find a Rust program that is (perforce) not using powerful libraries, can I be confident that it does not harbor grave errors? Certainly not. Rust takes aim at memory errors, and misses the rest that would be avoided by encapsulating bug-prone code in libraries. C++ enables capturing bug-prone code in well-tested libraries, eliminating whole families of bugs, including, in my recent experience, memory bugs. That…

> If I find a Rust program that is (perforce) not using powerful libraries, can I be confident that it does not harbor grave errors?

You can be confident that it doesn't harbour memory errors. You can be confident that it doesn't contain arbitrary code execution bugs, which is a much better circumstance than with any C++ project I've seen (C++ by its nature turns almost any bug into a security bug).

IME you can also have a much higher level of confidence that it does what you expect (including not having bugs) than you would for a C++ project, because of Rust's more expressive type system.

> C++ enables capturing bug-prone code in well-tested libraries, eliminating whole families of bugs, including, in my recent experience, memory bugs.

And yet in practice you can neither be confident that there are no memory bugs, nor that there are no other bugs. Even the big name C++ libraries are riddled with major bugs. Perhaps libraries that are written in a certain fashion avoid this bugginess, but that's of little use when it's not possible to tell from a glance whether a given library is one of the buggy ones or not.

Re: Modern C++ Won't Save Us

#338

Post by lmm »

jstimpfle wrote: post #321
lmm wrote: post #316

Earlier quoted context omitted.

You mean start by building something that can be used and tested in isolation, rather than trying to build an enormous system in one go? Isn't that what you've been arguing against?

No I mean solve the problem "we need to build a program that does what it's required to do" (and no more) before trying to build a library that will cure diseases.

That's a total non sequitur. Libraries can, and usually should, be much smaller than applications.

Re: Modern C++ Won't Save Us

#339

Post by jstimpfle »

lmm wrote: post #338
jstimpfle wrote: post #321

Earlier quoted context omitted.

No I mean solve the problem "we need to build a program that does what it's required to do" (and no more) before trying to build a library that will cure diseases.

That's a total non sequitur. Libraries can, and usually should, be much smaller than applications.

Libraries are much harder than applications because they must work for a large number of applications with diverse requirements. They need to be more abstract, and therein lies the danger.

Regarding the size, clearly wrong. It depends a lot on the library. A windowing or font rastering library will be a lot larger than your typical application.

And for libraries that are much smaller than the application itself, why bother depending on them? (Anecdote, I heard the Excel team in the 90s had their own compiler).

Re: Modern C++ Won't Save Us

#340

Post by sorenjan »

whyever wrote: post #326
sorenjan wrote: post #287

Earlier quoted context omitted.

What's the modern C++ equivalent to C's (rand() % (b - a)) + a; or Python's random.randint(a, b) Easy to use and often good enough.

> (rand() % (b - a)) + a; This is no longer uniform, because it introduces a bias towards small numbers.

Yes, it's less than ideal. But like I said, often good enough. Sometimes you just want a simple way to get something approximately random, the actual distribution might be unimportant.
Post reply on HN