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

321–330 of 395 posts

Re: Modern C++ Won't Save Us

#321

Post by jstimpfle »

lmm wrote: post #316
jstimpfle wrote: post #312

Earlier quoted context omitted.

> But if we believe in using libraries then often our project will itself be a library. How about making the project good first? Let's try to get something done instead of theoretizing.

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.

Re: Modern C++ Won't Save Us

#322

Post by ncmncm »

lmm wrote: post #254
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. Can you write down the algorithm that you use to avoid writing memory bugs? Can you teach others how to do it? Experienced C++ programmers do seem to learn how to avoid those bugs (although very often what they write is still undefined according to the standard - but e.g. multithreading bugs may be rare enough not to be…

>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 certainly niches for less powerful languages. Rust is more powerful, and nicer to code in, than many that occupy those. It will completely displace Ada, for example.

Re: Modern C++ Won't Save Us

#323

Post by ncmncm »

kibibu wrote: post #284
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 haven't written c++ seriously for a number of years. Do you still have to do all that "rule of three" boilerplate stuff to use your classes with the STL? Is it better or worse now with move constructors?

So, so much better. Nowadays we "use" what has been called "rule of zero". Write a constructor if you maintain an invariant. Rely on library components and destructors for all else.

Re: Modern C++ Won't Save Us

#324

Post by ncmncm »

fetbaffe wrote: post #220
vasilipupkin wrote: post #130

Earlier quoted context omitted.

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.

> with well design class hierarchies :eyes:

He rolls his eyes at "hierarchies". Libraries do make the difference.

Somebody else interjected Design Patterns. You can define a design pattern as a weakness in your language's ability to express a library function to do the job.

Re: Modern C++ Won't Save Us

#325

Post by aliceryhl »

maccard wrote: post #301
simias wrote: post #248

Earlier quoted context omitted.

This is solved in Rust by letting you test and unwrap at the same time: if let Some(obj) = my_optional { do_stuff(obj); } >However if the dereferencing, my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed So basically that turns C++ optional types into fancy linter hints which won't actually…

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.

Re: Modern C++ Won't Save Us

#326

Post by whyever »

sorenjan wrote: post #287
blt wrote: post #127

Earlier quoted context omitted.

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)

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.

Re: Modern C++ Won't Save Us

#327

Post by ncmncm »

esrauch wrote: post #196
gmueckl wrote: post #185

Earlier quoted context omitted.

That is why use tools like valgrind to verify that you got it right.

When I worked on a mobile C++ project at Google, we went exceptionally out of our way to avoid memory issues. We ran under valgrind and multiple sanitizers (and continuously ran those with high coverage unit and integration tests). We ran fuzzers. We had strictly enforced style guides. We still shipped multiple use after frees and ub-tripping behavior. I also saw multiple issues in other major libraries that we were…

Yes, I know how you code are obliged to code at Google. It is astonishing that anything works.

The "strictly enforced style guides" strictly enforce '90s coding habits.

Re: Modern C++ Won't Save Us

#328

Post by lmm »

ncmncm wrote: post #322
lmm wrote: post #254

Earlier quoted context omitted.

> It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. Can you write down the algorithm that you use to avoid writing memory bugs? Can you teach others how to do it? Experienced C++ programmers do seem to learn how to avoid those bugs (although very often what they write is still undefined according to the standard - but e.g. multithreading bugs may be rare enough not to be…

>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.

Re: Modern C++ Won't Save Us

#329

Post by whyever »

netheril96 wrote: post #183
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.

Most other random libraries, in whatever languages, do not even offer the option of this "right" version of initialization. They all just seed with a 32-bit integer. If you are content with those libraries, you should be content with a simple `std::mt19937{std::random_device{}()}`.

I don't think this is true for modern languages.

Rust seeds the whole state by default: https://docs.rs/rand/0.6.5/rand/

Julia seems to seed 128 bits: https://github.com/JuliaLang/julia/blob/5741c7f53c5ea443bbd7...

However, your statement seems to apply to old languages:

C# uses only 32 bits and the time for seeding: https://docs.microsoft.com/en-us/dotnet/api/system.random?vi...

Java only supports 48 bit seeds: https://docs.oracle.com/javase/8/docs/api/java/util/Random.h...

Re: Modern C++ Won't Save Us

#330

Post by MiroF »

hermitdev wrote: post #73
MiroF wrote: post #54

Earlier quoted context omitted.

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

I guess the point I was trying to make is that what is referred to colloquially as dereferencing is different than how the compiler sees it. We see " foo" (can't get HN to emit the asterisk for pointer dereference here, no matter what I try ), and we know that to be UB, but the compiler doesnt really see it until the load. Until its actually used, its effectively a dead store and will be eliminated, anyway. int& bar…

The problem is that we don't know what the compiler might think..

If I write something along the lines of

  int& bar = *foo

  if(!foo) {
    // do something
  }
The compiler very well might (and would be perfectly within its rights to) completely eliminate everything inside of the if(!foo) since it can assume the pointer is non-null because it is being dereferenced.
Post reply on HN