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

281–290 of 395 posts

Re: Modern C++ Won't Save Us

#281

Post by geofft »

Vogtinator wrote: post #182
geofft wrote: post #62

Earlier quoted context omitted.

All of those problems are long-term solved by using more Rust, whereas none of C++'s problems are long-term solved by using more C++. (Personally, I don't find single-vendor or lack of standardization a problem in practice, and I've never written C++ for a platform Rust doesn't support.)

Both of them can be solved by giving it more time, but C++ is currently way ahead.

I'm not sure that's true. Giving C++ 30 years has resulted in the things identified in the article. (In particular, giving auto_ptr 20+ years hasn't resulted in anything that really fixes the problem.) It is not clear to me that it's moving in the right direction, so I don't think more time will help. C++ is definitely ahead in popularity but is neither ahead not obviously aimed in the right direction in safety.

Giving Rust about ten years has resulted in significant growth in popularity and tooling, including attempts to write new implementations of the language (e.g., mrustc), so given more time and in particular given more production users, it seems reasonable to expect it will figure all those things out.

Re: Modern C++ Won't Save Us

#282

Post by tatersolid »

AnimalMuppet wrote: post #96
leshow wrote: post #84

Earlier quoted context omitted.

It was presented to show the "just use modern c++" counterargument to discussing the unsafety of c++ isn't a great argument. There are modern parts that are still unsafe.

Fair enough. But tatersolid seems to be condemning the entire language, which is a step too far for the evidence given.

40 years of security vulnerabilities in C and C++ code is plenty of evidence to condemn those languages as unfit for most purposes.

The evidence is overwhelming that it is not possible to write non-trivial C or C++ that is safe in the face of adversarial input. Microsoft, Google, Oracle, Linus, etc. have all tried for decades and failed miserably. All the resources and expertise in the world still results in unsafe software when C and C++ are used.

Re: Modern C++ Won't Save Us

#283

Post by lmm »

jstimpfle wrote: post #279
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? Structure the code in a way such that it is obvious what happens. Use "semantic compression" (e.g. be clear about your concepts and factor them in free standing functions), but don't overabstract/overengineer. Eliminate special cases. If the code has few branches and data dependendencies, then successful m…

> Structure the code in a way such that it is obvious what happens. Use "semantic compression" (e.g. be clear about your concepts and factor them in free standing functions), but don't overabstract/overengineer.

This sounds little different from "write good code, don't write bad code." I'm sure we all agree on these things, but I'm sure the people who write terrible code weren't trying to be unclear or trying to overengineer.

> Eliminate special cases. If the code has few branches and data dependendencies, then successful manual testing gives already high confidence that it will be pretty robust in production.

True enough, but that's so much easier in a language with sum types.

> Prefer global allocations (buffers with the same lifetime as the process), not local state. This also makes for much clearer code, since it avoid heavy plumbing / indirections.

That's a pretty controversial viewpoint, since it makes composition impossible (indeed taken to its logical extreme this would mean never writing a library, whereas the grandparent was convinced that more use of libraries was the way to write good code).

> I tend to think that modern programming language features mostly enable us to stay longer with bad structure. And when you hit the next road block, fixing that will be correspondingly harder.

Interesting; that's the opposite of my experience. I find modern language features mostly guide us down the path that most of us already agreed was good programming style, enforcing things that were previously only rules of thumb (and that we had to resist the temptation to bend when things got tricky). And so the modern language forces you to solve problems properly rather than hacking a workaround, and the further you scale the more that will help you.

Re: Modern C++ Won't Save Us

#284

Post by kibibu »

paulmooreparks wrote: post #134
Tracist wrote: post #116

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. The whole comment sounds so much like well written satire, but I think he's being serious.

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?

Re: Modern C++ Won't Save Us

#285

Post by kaens »

pjmlp wrote: post #275
kiriakasis wrote: post #257

Earlier quoted context omitted.

I never understood this type of comments, is what you are trying to say something like: "It was already tried and failed, why is this time better" "Mainstream languages always end up not using it" "People should reference more the original works of the past" ... One of the many explainations of the name Rust is that it represents a collection of old ideas. What was the point you were trying to convey in specific?

People should reference more the original works of the past instead of rediscovering them

I think more rediscoveries may be references than you suspect, but in the cases that are rediscoveries there is a bit of a knowledge and discoverability issue for PL features for people who aren't PL nerds already.

I'd love it if more people had a more solid understanding of the ideaspaces that have been covered in the PL landscape, but considering that most common paths to working in software (and even to creating and contributing to langs) don't involve needing to know PL history I'm not sure how to get there from here.

If you have resources you think people should be utilizing here, please speak up.

Re: Modern C++ Won't Save Us

#286

Post by whyever »

Vogtinator wrote: post #182
geofft wrote: post #62

Earlier quoted context omitted.

All of those problems are long-term solved by using more Rust, whereas none of C++'s problems are long-term solved by using more C++. (Personally, I don't find single-vendor or lack of standardization a problem in practice, and I've never written C++ for a platform Rust doesn't support.)

Both of them can be solved by giving it more time, but C++ is currently way ahead.

I don't think that C++'s memory safety issues can be solved by giving it more time.

Re: Modern C++ Won't Save Us

#287

Post by sorenjan »

blt wrote: post #127
millstone wrote: post #98

Earlier quoted context omitted.

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)

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.

Re: Modern C++ Won't Save Us

#288

Post by jstimpfle »

lmm wrote: post #283
jstimpfle wrote: post #279

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? Structure the code in a way such that it is obvious what happens. Use "semantic compression" (e.g. be clear about your concepts and factor them in free standing functions), but don't overabstract/overengineer. Eliminate special cases. If the code has few branches and data dependendencies, then successful m…

> Structure the code in a way such that it is obvious what happens. Use "semantic compression" (e.g. be clear about your concepts and factor them in free standing functions), but don't overabstract/overengineer. This sounds little different from "write good code, don't write bad code." I'm sure we all agree on these things, but I'm sure the people who write terrible code weren't trying to be unclear or trying to over…

>> Eliminate special cases. [...] > True enough, but that's so much easier in a language with sum types.

These languages make it easier to have more special cases. There's a difference.

> That's a pretty controversial viewpoint, since it makes composition impossible (indeed taken to its logical extreme this would mean never writing a library, whereas the grandparent was convinced that more use of libraries was the way to write good code).

I don't see why that should be the case. Aside from the fact that composition/"reuse" is way overrated, libraries can always opt for process- or thread-wide global state. Another possibility would be to have global state per use (store pointer handles), and passing a pointer only to library API calls. The latter is also the most realistic case since most libraries take pointer handles. I absolutely have these handles stored in process global data. For example, Freetype handle, windowing handle, sound card handle, network socket handle, etc.

Also called "singleton" in OOP circles. Singletons are nothing but global data with nondeterminstic initialization order and superfluous syntax crap on top. Other than that, they are indeed good choices (as is global data) since lifetime management and data plumbing is a no-brainer.

> I find modern language features mostly guide us down the path that most of us already agreed was good programming style

But just the paragraph before you said you didn't agree with mine? In my opinion, OOP, or more specifically, lots of isolated allocations connected by pointers/references, make for hard to follow code since there is so much hiding and indirection even within the same project/maintenance boundaries without benefit. In any case I absolutely agree that this style is not doable in C. You need automated, static or dynamic (runtime) ownership tracking.

Re: Modern C++ Won't Save Us

#289

Post by Kranar »

fooker wrote: post #221
usrnm wrote: post #131

Earlier quoted context omitted.

Good luck implementing something like std::is_standard_layout without "magic language hacks". No, not all libraries are made equal and std is part of the language now, there is no way back

A look into the type_traits header reveals that is_standard_layout is implemented with standard C++.

This is absolutely false.

https://github.com/llvm-mirror/libcxx/blob/master/include/ty...

Re: Modern C++ Won't Save Us

#290

Post by kevin_thibedeau »

AnimalMuppet wrote: post #82
kevin_thibedeau wrote: post #44

Earlier quoted context omitted.

Definitely not true. Consider an IoT device without an MMU.

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.
Post reply on HN