Live data from Hacker News

C++ Should Be C++

open-std.org

141–150 of 191 posts

Re: C++ Should Be C++

#141

Earlier quoted context omitted.

No, C is not the same as it is less expressive. C++ templates allow for declarative nested inlining into a single compilation unit that is extremely difficult to achieve with C macros. See elsewhere in this thread for discussion of boost, it's not applicable.

In this thread: all the people that have never looked at C++ disassembly. Maybe the C++ "language server" of your choice should have a mode where it prints all the constructors destructors copy constructors and what not on top of your code? "Zero cost abstraction" is a big fantasy. C++ is the king of hidden control flow and the costs are everywhere.

As someone who reads C++ disassembly/decompilation for a living... Yeah kinda. It depends.

If the target code is full of virtual function calls, yeah it gets gross. But if you need dynamic dispatch, C isn't going to be any better, you'll just be reinventing vtables by hand. Similarly, resource acquisition and release happens in C too, you just have to do it by hand instead of letting the destructor do it for you.

One ultra gross thing I see all the time in C++ disassembly though: constantly creating copies of a std::string, using them once for a comparison or something trivial, and then throwing them away. Multiple times in the same function. Its the developers fault, they shouldn't be creating new objects, they should be passing a pointer or a string_view or something. Unfortunately, C++ is copy rather than move by default, so its too easy to do this by accident.

Another gross thing? (Not C++ specific) 20 functions in a row that are just a single return instruction. Since functions have to have distinct addresses (that's my understanding at least) the compiler/linker can't easily fold identical functions together. Implementations can optimize as long as everything still works (the "as-if" rule). And I know some compilers do. But in practice, it seems they suck at it. So I get to look at 20 lines of assembly in a row that are just `bl`.

Re: C++ Should Be C++

#142
post #99
post #51

Earlier quoted context omitted.

And the additional trade-off that some bugs are only noticed at runtime when that particular line is executed while it could have been noticed by the compiler of a strongly typed language. Pytype helps but at this point you have a static analyzer that potentially runs as slow as a compiler without the additional performance benefit.

There’s no good reason for type checking to be super slow. I’m no fan of Go, but the language compiles insanely fast while being fully statically typed. As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. This isn’t a problem with static typing. It’s a problem with C++, and to a lesser extent C.

(one of the reasons Go compiles fast is its compiler is really bare bones, comparatively speaking it does very little in the optimization area vs what you would see out of .NET and JVM implementations, not even mentioning GCC or LLVM)

Re: C++ Should Be C++

#143

> What is much less prevalent is a demand from average C++ users for memory safety features; they’re much more concerned about compilation speed. When most C++ developers haven’t adopted tools like Coverity and C++ core guidelines checkers, it is hard to claim that memory safety features substantially improve their lives at least from their point of view. I don’t really agree with this. There’s also a group of develo…

Yeah that stood out to me too. I guess the problem is that only a small percentage of developers both understand the need for memory safety and are vocal about it. That is very different from the number of users who would benefit from better memory safety.

When someone encounters a crash, their actionable item isn’t to go ask the C++ committee for better safety. That’s an unassailable wall for most developers, assuming they even understand what’s happening and that there are better options out there.

Re: C++ Should Be C++

#144
post #8

Nevermind the language itself, we need a way to pull compilers and project dependencies, pinned to their specific versions, with a single, ergonomic tool. vcpkg seemed really promising but the fact that they didn't start with library versioning from the get go was a very stupid decision, and nowadays versions are pinned to specific commit hashes rather than actual dependency versions, and libraries that weren't previ…

Until then there is Nix/Guix and Bazel/Buck.

Re: C++ Should Be C++

#145

Honestly, everyone working with C++ sticks to a select subset of the language that they've chosen for their project, or the project they're contributing to. Nobody knows all of C++. Personally, I don't mind C++ forking out in different directions and accepting diverse proposals; while I wouldn't bother to use them myself, I realize that it may be useful to other people. C++ is an engineer's language, and it's ridicul…

> Yes, there are memory safety issues, but in practice, these are isolated in very few places. Take a compiler like LLVM for instance: most developers are working on transforms or analyses, and they're exposed to zero manual memory management.

It is really easy to get use-after-free in LLVM passes due to using eraseFromParent() instead of removeFromParent(), etc. As I recall, in some places the optimization code goes through really awkward patterns in order to keep track of the IR nodes that are dead to avoid UAF, none of which would be necessary if LLVM were written in a GC'd language. (Note: I'm not saying LLVM should be written in a GC'd language.)

Re: C++ Should Be C++

#146

Earlier quoted context omitted.

It's both and neither. Some countries are considering legislation to require "memory-safe" tooling for "critical" workloads, and C++ has never been placed on the "memory-safe tooling" list.

Which countries? Can you share the reporting on this legislation? I’d be very interested.

The best forecast I know is Sean Parent's on ADSP episode 160.

[0:23:57] SP: We're also discussing internally around pending legislation around safety and security, what Adobe's response is going to be. Right now our thinking is we would like to publish a roadmap on how we're going to address that. That is not finalized yet in any form, but I expect a component of that roadmap is going to be that some of our critical components will get rewritten into Rust or another memory-safe language.

[0:24:28] CH: When you say "pending legislation", is that a nod to some pending legislation that you actually know is on the horizon? Or just anticipating that it's going to happen at some point?

[0:24:38] SP: Oh yeah, no. There are two bills (sorry I don't have...)

[0:24:44] CH: It's all right, we'll find them and link them in the show notes afterward.

[0:24:48] SP: Yeah, I can hunt down the links. The one in the U.S. that's pending basically says that the Department of Defense is going to within 270 days of the bill passing (and it's a funding bill which means it will probably pass late this year - early next year) that the Department of Defense will establish guidelines around safety and security including memory safety for software products purchased by Department of Defense. The E.U. has a similar wording in a bill that's slowly winding its way through their channels. I don't have insight into when that will pass. The U.S. one will almost certainly pass here within a month or two.

[0:25:43] CH: Oh. Wow.

[0:25:44] SP: There's a long way between having a bill pass that says almost a year later they have to establish a plan for what they're going to do, right. So it's not hard legislation in any way. But I view this-- I can send you a link. There was a podcast I listened to recently on macOS folklore. [...] It's talking about how in the early '90s there was a somewhat similar round of legislation that went around around POSIX compliance. Basically the Department of Defense decided that in order to have portable software, every operating system that they purchased had to have POSIX compliance. And there was a roadmap put into place. That's why Apple pursued building their own UNIX which was A/UX and eventually partnered with IBM to do AIX. And Microsoft in the same timeframe had a big push to get POSIX compliance in Windows OS. The thinking was eventually in order to sell to the government your operating system it would require POSIX compliance. What actually happened, if you wanted to buy just traditional Macintosh operating system you would just say "well I require Photoshop or pick-your-application and there is no alternative that runs under UNIX so therefore I need an exception to buy macOS" and it was extra paperwork but it got signed off on. So really never materialized into hard restrictions on sales of non-POSIX-compliant OSes. I expect the safety legislation to take somewhat the same route, which is, there will be pressure to write more software in memory-safe languages. When you don't write software in memory-safe languages there is going to be more pressure for you to document what your process is to mitigate the risks. And this is initially all in the realm of government sales, although there is some discussion in both the E.U. legislation and on the U.S. side of extending this to a consumer safety issue. But there will be an escape hatch because you couldn't wave any kind of magic wand as a legislator and say "you can't sell software anymore if it's written in C++". The world would grind to a halt. So there will be an escape hatch, and there will be pressure. So as a company you have to look at how are you going to mitigate that risk going forward. And what's your plan going to be so that you can continue to sell products to the government. And how do you make sure that you're not opening up a competitive threat. If you've got a competitor that can say "well we're written entirely in Rust so we don't have to do the paperwork" that becomes a faster path. So you want to make sure that you're aware of those issues and that you've got a plan in place to mitigate them.

Re: C++ Should Be C++

#147

Earlier quoted context omitted.

Which countries? Can you share the reporting on this legislation? I’d be very interested.

The best forecast I know is Sean Parent's on ADSP episode 160. [0:23:57] SP: We're also discussing internally around pending legislation around safety and security, what Adobe's response is going to be. Right now our thinking is we would like to publish a roadmap on how we're going to address that. That is not finalized yet in any form, but I expect a component of that roadmap is going to be that some of our critical…

Thank you. I have mostly heard people confusing the CISA stuff with "legislation," but this sounds like something that is actually legislation. I'll have to dig into it. Thank you.

Re: C++ Should Be C++

#148

The C++ community has some of the best brains around. Absolute geniuses. If C++ is ok with being a small language used by and for geniuses - I have no problem with that. If C++ wants to be popular - we need a breaking change between the world of 2023 and 1990 - they don't know what we know now. I like some parts of C++... it's too bad the "good language" is shackled to a mountain of razor blades.

What do you think about Carbon[1]? I am hopeful.

[1] https://github.com/carbon-language/carbon-lang

Re: C++ Should Be C++

#149
post #37

Earlier quoted context omitted.

That sentence stood out to me as well. I don't think C++ developers is necessarily the best people to ask when discussing whether memory safety is important and urgent to work on or not. A lot of developers are relatively shielded from the consequences of bugs and security vulnerabilities, either by their programs not being exposed to the wild in any major sense or by bureaucracy being in between them and any consequ…

> the deficiencies of a language becomes a concern for its end-users rather than its developers. I think that this level of professional malpractice is something that can't be solved by language choice.

But the level of damage can be reduced by language choice

Re: C++ Should Be C++

#150

Earlier quoted context omitted.

Awful analogy. C++'s fitness as a general-purpose programming language is not an exclusive assertion.

That's not the point. The point is that "N people can't be wrong" is not a valid argument for any value of N.

It's a programming language that has been used by lots of people in a lot of different contexts. The author of the article think it's a good definition for "general purpose programming language". The original author has never said "N people can't be wrong", it's the reframing of top comment. You can disagree with the "general pupose"-ibility of C++ but I don't think it's an honest way to interpret the argumentation of the author of the article.
Post reply on HN