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

Safe C++ proposal is not being continued

sibellavia.lol

Post reply on HN
Print view View original

111–120 of 226 posts

Re: Safe C++ proposal is not being continued

#111

Post by pjmlp »

jandrewrogers wrote: post #86
Animats wrote: post #39

Earlier quoted context omitted.

Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. True. So many proposals have gone by over the years. Here's one of mine from 2001.[1] Bad idea. The layers of cruft in C++ have become so deep that it's a career just to understand them. DARPA has something called the TRACTOR program, "Translate All C to Rust". It's been underway for a year, and they hav…

I think something less obvious to people is that type inheritance in C++ has several uses outside of building naive object hierarchies. Even if your model is based on composition as is typically the case these days, inheritance is a useful tool for expressing some metaprogramming mechanics and occasionally literal old style inheritance is actually the right thing to do. You don’t need it most of the time but sometime…

Sadly we got concepts lite instead of C++0x concepts, so while better than SFINAE or tag dispatch, it is still half solution, and it won't get better because those behind it, eventually went on to Swift, and nowadays Hylo.

Re: Safe C++ proposal is not being continued

#112

Post by silon42 »

gmueckl wrote: post #63
coffeeaddict1 wrote: post #45

Earlier quoted context omitted.

> And you could force all lifetime operations to use C++ stdlib refcounting primitives, and then have lifetime safety in a Swift-like way (i.e. eager refcounting everywhere) That's going to be a non-starter for 99% of serious C++ projects there. The performance hit is going to be way too large. For bounds checking, sure I think the performance penalty is so small that it can be done.

You have to realize that the number of locations in code where reference counter adjustment is actually meaningful is rather small and there are simple rules to keep the excess thrash from reference counting pointer wrappers to a minimum. The main one, as mentioned in the talk the sibling comment called out, is that it is OK to pass a raw pointer or reference to a function while holding on to a reference count for as…

Maybe C++ should copy some Swift, before attempting to challenge Rust.

Re: Safe C++ proposal is not being continued

#113

Post by pjmlp »

pizlonator wrote: post #61
tialaramex wrote: post #57

Earlier quoted context omitted.

Yes I can be specific. Firstly, you need composition. Rust's safety composes. The safe Rust library for farm animals from Geoff, the safe Rust library for cooking recipes by Alice and the safe Rust library for web server by Bert together with my safe program code adds up to my safe Rust farm foods web site. By having N profiles, where N is intended to be at least five and might grow arbitrarily and be user extensible…

I think the point is that folks will incrementally move their code towards having all profiles enabled, and that's sort of fundamental if the goal is to give folks with C++ codebases an incremental path to safety. So I don't buy your first and second points. > Which comes to the third part. Once you start down this path, as they found, you realise you actually want a borrowck. That's a bold statement. It might be tru…

> I think the point is that folks will incrementally move their code towards having all profiles enabled, and that's sort of fundamental if the goal is to give folks with C++ codebases an incremental path to safety.

I doubt it, because the reason I favoured C++ over C back in 1993, was the safety culture, as someone coming from Turbo Pascal.

Somehow this has been deteriorating since 2000, as C++ kept getting C refugees that would rather keep using C, but work required C++ now.

Most of the hardening capabilities that are being added now, were already part of the compiler frameworks during the 1990's, e.g. Turbo Vision, OWL, MFC, CSet++, MFC, MacApp, PowerPlant,...

Re: Safe C++ proposal is not being continued

#114

Post by vintagedave »

Voultapher wrote: post #99
tialaramex wrote: post #18

I am actually much more pessimistic about Profiles than Simone. Regardless of the technology the big thing Rust has that C++ does not is safety culture , and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon. The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen min…

I came to the same conclusion in a talk I gave to the Munich C++ Meetup [1]. There is a prevalent culture of expecting users to not make mistakes. Library constructs that could be significantly safer-to-use are kept easy-to-use incorrectly, usually with the argument of performance. The irony is that if you look closer, the performance optimization that was done is removing the seatbelts from a small hatchback to safe…

A year or so ago I read that there was a design decision railroaded through the committee about what kind of safety approach could be looked at. Its wording effectively prevented Safe C++. I was not at this meeting so I’m going on what others say:

https://www.reddit.com/r/cpp/comments/1hppdzc/comment/m4jjo4...

I’m a big fan of Safe C++ and believe its approach — learning from another language, incremental opt-in (just like all good refactorings, work on code and improve it piece by piece) — would have been the path that solved some genuine problems. Profiles seem a hodgepodge. And — to share personal worries about what I read into what comments like the above imply, this is not a statement — I worry deeply about the relationship between who proposes what, and who has pricklier personalities or less connections, with what approach was accepted.

I wish Safe C++ would continue as a hard fork of the language.

Re: Safe C++ proposal is not being continued

#115

Post by notmywalrus »

int_19h wrote: post #89
tialaramex wrote: post #26

Earlier quoted context omitted.

Well. What other examples of this feat are you thinking of? To me the things which come to mind are either compiler magic (e.g. C printf) or they rely on RTTI (e.g. Odin and similar C-like languages) and neither of those is what fmt does, they're "cheating" in some sense that actually matters.

https://doc.rust-lang.org/std/macro.format.html https://zig.guide/standard-library/formatting/

Rust is an example of "compiler magic" in this case.

You're right about Zig, and reading the source [1] I'm still kind of impressed how unified they made comptime / runtime.

[1]: https://github.com/ziglang/zig/blob/32a1aabff78234b428234189...

Re: Safe C++ proposal is not being continued

#116

Post by pjmlp »

Rusky wrote: post #77
pizlonator wrote: post #36

Earlier quoted context omitted.

> The profiles technology isn't very good. Can you be very specific about why? Here's the argument for why profiles might work: with all of the profiles enabled, you are only allowed to use the safe subset of C++ and all of the unsafe stuff is hidden behind APIs whose implementations don't have those profiles enabled. Those projects that enable all profiles by default effectively get Swift-like or Rust-like protectio…

If that is what profiles were actually doing, it would probably make sense. But it's not what profiles are doing. Instead, for example, the lifetime safety profile ( https://github.com/isocpp/CppCoreGuidelines/blob/master/docs... ) is a Rust-like compile time borrow checker that relies on annotations like [[clang::lifetimebound]], yet they also repeatedly insist that profiles will not require this kind of annotation…

Additionally they ignore field experience, I can tell that on VC++ the lifetime checker only has worked in small examples, as I was really into trying it out.

Microsoft even has blog posts admitting that only with SAL like annotations it can be improved, while keeping the usual C++ semantics.

Yet WG21 has ignored this field experience.

Re: Safe C++ proposal is not being continued

#117

Post by pjmlp »

silon42 wrote: post #112
gmueckl wrote: post #63

Earlier quoted context omitted.

You have to realize that the number of locations in code where reference counter adjustment is actually meaningful is rather small and there are simple rules to keep the excess thrash from reference counting pointer wrappers to a minimum. The main one, as mentioned in the talk the sibling comment called out, is that it is OK to pass a raw pointer or reference to a function while holding on to a reference count for as…

Maybe C++ should copy some Swift, before attempting to challenge Rust.

It has already multiple times,

Managed C++, C++/CLI, C++/CX, C++ Builder, Unreal C++

But those aren't extensions or approaches WG21 cares about having.

The C++11 GC design didn't even took those experiences into consideration, thus it got zero adoption, and was dropped on C++20.

Re: Safe C++ proposal is not being continued

#118

Post by pjmlp »

TinkersW wrote: post #8
LorenDB wrote: post #2

The title has potential to be a bit misleading, because as the article says, while Sean Baxter's proposal is not being continued, the committee is working on the Profiles proposal, which still will enable some level of safety. So C++ is still working towards safety, just not the Safe C++ safety.

Hardware level safety will arrive first(see Apple support for Memory Integrity Enforcement ), not as fool proof as SafeC++/Rust but no need to change code...

It has been already here since 2015 on Solaris SPARC.

Re: Safe C++ proposal is not being continued

#119

Post by dagmx »

MattDamonSpace wrote: post #85
usamoi wrote: post #58

They are not rejecting Safe C++; they are rejecting memory safety. Majority of them believes that memory safety is just hype, and minority of them knows it's a problem, but doesn't want to restrict themselves about coding. If code runs, it is fine. If it does not, coder running is fine too.

I work on a Swift/iOS app that wraps a C++ library 90+% of our crashes are from hard-to-diagnose cpp crashes. Our engineers are smart and hardworking but they throw their hands up at this. Please tell me my options aren’t limited to “please be better at programming”…?

Have you tried enabling asan? It’s not really the same kind of language guarantees but it does catch a lot of the same errors.

In general I think static analysis is a crutch for C++ to claim safety but it is still a very useful tool that devs should use in development.

Re: Safe C++ proposal is not being continued

#120

Post by pjmlp »

int_19h wrote: post #9
quotemstr wrote: post #5

Okay, so treat the C++ standards committee the same way the HTML5 people treated W3C. If they insist on making themselves irrelevant, let them. Profiles cannot achieve the same level of safety as Rust and it's obvious to anyone who breathes. Profiles just delete stuff from the language. Without lifetimes reified as types you can't express semantics with precision enough to check them. The moment string_view appears,…

The reason why WHATWG was able to take over HTML like that is because all the people & companies that were actually making the browsers were onboard. With C++, my impression is that most implementers simply aren't interested. And, conversely, most people who might be interested enough to roll a new implementation have already moved to Rust and make better use of their time improving that.

You right, because the main companies with OSes that contribute to the surviving compilers that still care about ISO, are now focused elsewhere.

Apple with Swift, Google with Go, Java/Kotlin, Rust, Microsoft with C#, Go, Java and Rust.

Most modules stuff on GCC was done by a single developer, if I am not mistaken.

Notice how Visual C++ blog posts are mostly about game development related improvements, Visual Studio tooling.

Everyone else their compilers are still stuck on C++14, or C++17 if lucky.

Post reply on HN