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

Modern C++ Won't Save Us (2019)

alexgaynor.net

Post reply on HN
Print view View original

41–50 of 266 posts

Re: Modern C++ Won't Save Us (2019)

#41

Post by FpUser »

Those C++ bad, complex, unsafe etc. etc articles are starting to get boring.

If one wants to shoot him/herself in a foot it is fine. C++ offers countless possibilities.

It (and plethora of libraries) also offers quick way to write sophisticated and performant applications without much fuss.

Make your choice. I personally use C++ to great advantage and find it very productive and safe. And while being good programmer / designer I am not a C++ expert. Far from it.

Or use language of your choice. Nothing is wrong with it. We do not have to live in the world where "there can be only one".

Re: Modern C++ Won't Save Us (2019)

#42

Post by andyxor »

geofft wrote: post #35
andyxor wrote: post #14

C++ is a beautiful, pragmatic and very efficient language, just constrain your use of it to STL, and avoid Boost and other over-engineered dependencies. The Ockham's razor principle of code design is not only important but essential when using large mature languages that have many surprising and nuanced ways to skin a cat. Being too clever with C++ is a recipe for disaster. Avoid OOP (inheritance in particular) and t…

I'm not sure I understand your points about Boost - everything the article discusses is in the STL, is it not? I'm also not sure I understand your point about being too clever and template metaprogramming - nothing the article discusses involves template metaprogramming, and I'd say it's doing very straightforward things. Do you think some part of this is too clever? Also, I'm not sure I understand how to reconcile y…

STL and OOP are orthogonal, e.g. you can use STL without ever using the concept of inheritance.

Boost is too popular imo, and many people take it for granted when using C++ that it comes with this nice utility library to complement STL, kind of like another python package, no big deal.

From what I've seen on multiple projects it creates an explosion of poorly understood (and often poorly implemented) dependencies which leads to maintenance nightmare, memory leaks and bugs, performance issues and production outages.

If you can avoid using an external dependency such as a gigantic library full of experimental features created by thousands of C++ enthusiasts avoid it at all costs. as it tempts the team to use it left and right when it's not really needed, just like templates.

Templates, if used without strictly complying to the KISS principle can get unwieldy, full of nuanced, intricate and unnecessary abstraction, and make it hard to understand and maintain the code

C++ is a giant language and its use on a particular project has to be very tightly constrained to a very minimal set of features and dependencies.

Re: Modern C++ Won't Save Us (2019)

#43

Post by notacoward »

HexDecOctBin wrote: post #34
Animats wrote: post #24

My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…

> three issues: "How big is it", "Who owns it", and "Who locks it" The issue with this kind of thinking is the belief that there is a "it", not "they". Say, you are writing a HTTP server [1]. A beginner mindset (what seems to be demonstrated in this post) with start allocating left and right, for every HTTP header, for every piece of string, for every piece of metadata record, etc. Thus, "how big is it" become no big…

> You allocate a memory arena when the HTTP request comes.

The per-request-arena concept is one of the most powerful and IMO underappreciated tools out there for dealing with memory-lifetime issues. I've used it or advocated for its use at multiple jobs and projects, quite successfully, even for kernel code. Windows NT uses it in IRPs. Network code in both BSD and SysV did something pretty similar, at least in the long-before-Linux days. It's tried and true. Having a clear moment when things should be freed and an equally clear description of what those things are is wonderful.

That said, even games and network servers and storage drivers often have other complex data structures not related to individual requests. It's usually not hard to come up with rules for each of these, but the rules forced on you by something like STL might not be as convenient, performant, and/or verifiable as those you come up with yourself.

I hope that some day programmers will stop using memory-unsafe languages except when they really need to, and that when it is necessary those languages will give them the tools to solve those problems themselves instead of pretending they're already solved. They're not. Rust's borrow checker plus Zig's arena concept plus a couple more pieces might actually get us there. C++'s feature salad never will.

Re: Modern C++ Won't Save Us (2019)

#44

Post by gavinray »

creata wrote: post #27
Animats wrote: post #24

My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…

I'm not sure what you mean by "global analysis," but Rust's borrow checker doesn't do any analysis that I'd consider "global."

Data-flow analysis is what I assume the author meant. Fancy word for "reasoning about behavior at a level higher than just a syntax node" (usually within a function or module, possibly within an entire program though)

Both D and Rusts compilers do it, and I'm uncertain whether Zig's does but it may too.

Re: Modern C++ Won't Save Us (2019)

#45

Post by MontagFTB »

madhadron wrote: post #37
ppg677 wrote: post #36

Yet C++ is what Google, Facebook, Microsoft and others still use for their most mission critical software.

Mission critical software projects, by their nature are started rarely and make very conservative language choices. By its nature, much of it is old, so it's in C++. There's also a fair amount of it in C# and Java, too.

Wasn’t a lot of Facebook’s initial implementation php? I seem to recall they moved off it, or wrote a specialized compiler to speed it up.

Re: Modern C++ Won't Save Us (2019)

#46

Post by UncleMeat »

dataflow wrote: post #40
creata wrote: post #27

Earlier quoted context omitted.

I'm not sure what you mean by "global analysis," but Rust's borrow checker doesn't do any analysis that I'd consider "global."

"Global analysis" is specific compiler optimization terminology. It refers to analysis across so-called "basic blocks" (also compiler terminology). See here: https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/l...

That's not true. Global analysis is a synonym for interprocedural analysis, which crosses function boundaries. An intraprocedural analysis that crosses many basic blocks is still "local" rather than "global".

This slide deck is weird. I've taught 143 before. Where did this come from? Perhaps in really old stodgy terminology before there was any interprocedural anything people used the words this way? I really don't know any static analysis or compilers person who would consider "global analysis" to mean "intraprocedural analysis that considers more than one BB".

Re: Modern C++ Won't Save Us (2019)

#47

Post by mamcx »

AnimalMuppet wrote: post #8

> There are significant challenges to migrating existing, large, C and C++ codebases to a different language – no one can deny this. Nonetheless, the question simply must be how we can accomplish it, rather than if we should try. Um... no. Not every (or even most ) existing large C/C++ codebase should be migrated to another language. "But security vulnerabilities! And crashes!" I admit all that. But a program can be…

This mindset is the Cobol mindset.

Sound reasonable today.

Is crazy to keep it for long.

And the billons of dollars wasted on "fix" C/C++ with discipline have proven is the wrong.

Re: Modern C++ Won't Save Us (2019)

#48

Post by dataflow »

UncleMeat wrote: post #46
dataflow wrote: post #40

Earlier quoted context omitted.

"Global analysis" is specific compiler optimization terminology. It refers to analysis across so-called "basic blocks" (also compiler terminology). See here: https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/l...

That's not true. Global analysis is a synonym for interprocedural analysis, which crosses function boundaries. An intraprocedural analysis that crosses many basic blocks is still "local" rather than "global". This slide deck is weird. I've taught 143 before. Where did this come from? Perhaps in really old stodgy terminology before there was any interprocedural anything people used the words this way? I really don't k…

It's funny because I also remembered it as cross-function analysis, but when I went back to grab a link I saw this and thought maybe I'm mistaken somewhere, so I just used this definition. Oh well. Main thing I was just trying to convey was that it's technical terminology.

Re: Modern C++ Won't Save Us (2019)

#49

Post by HexDecOctBin »

notacoward wrote: post #43
HexDecOctBin wrote: post #34

Earlier quoted context omitted.

> three issues: "How big is it", "Who owns it", and "Who locks it" The issue with this kind of thinking is the belief that there is a "it", not "they". Say, you are writing a HTTP server [1]. A beginner mindset (what seems to be demonstrated in this post) with start allocating left and right, for every HTTP header, for every piece of string, for every piece of metadata record, etc. Thus, "how big is it" become no big…

> You allocate a memory arena when the HTTP request comes. The per-request-arena concept is one of the most powerful and IMO underappreciated tools out there for dealing with memory-lifetime issues. I've used it or advocated for its use at multiple jobs and projects, quite successfully, even for kernel code. Windows NT uses it in IRPs. Network code in both BSD and SysV did something pretty similar, at least in the lo…

Maybe I didn't express myself properly (English is not my native language), but the point wasn't that everyone should use Memory Arena™ instead of Smart Pointers™ or Borrow Checker™. I am not trying to sell a conference here :)

The point was, to put it in Mike Acton's words, "when there is one, there are many". Usually, things are grouped, perhaps semantically, and it make sense to think of them as a group rather than breaks them in pieces. Arenas are one rather simple grouping mechanism, but they are not the only one. Of course, explaining complex grouping will require explaining the associated problem-solution pair, which is obviously out of scope of a forum reply.

All I would say is, if one steps out of one-at-a-time thinking, and statically plans the dynamically happening data transformation, and therefore exploit patterns and relationships inherent in that data flow, programming in low level languages becomes much easier.

But you need to know the problem (really really know it), and you need to know the solution. Temet Nosce.

Re: Modern C++ Won't Save Us (2019)

#50

Post by UncleMeat »

dataflow wrote: post #48
UncleMeat wrote: post #46

Earlier quoted context omitted.

That's not true. Global analysis is a synonym for interprocedural analysis, which crosses function boundaries. An intraprocedural analysis that crosses many basic blocks is still "local" rather than "global". This slide deck is weird. I've taught 143 before. Where did this come from? Perhaps in really old stodgy terminology before there was any interprocedural anything people used the words this way? I really don't k…

It's funny because I also remembered it as cross-function analysis, but when I went back to grab a link I saw this and thought maybe I'm mistaken somewhere, so I just used this definition. Oh well. Main thing I was just trying to convey was that it's technical terminology.

Yeah that's so bizarre. Is this Alex's slide deck? Did a TA write it? Could it be tremendously old? Weird.
Post reply on HN