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

191–200 of 226 posts

Re: Safe C++ proposal is not being continued

#191

Post by motorest »

IshKebab wrote: post #106
WalterBright wrote: post #74

Earlier quoted context omitted.

D adds a lot to memory safety without needing to struggle with program redesigns that Rust requires. These include: 1. bounds checked arrays (you can still use raw pointers instead if you like) 2. default initialization 3. static checks for escaping pointers 4. optional use of pure functions 5. transitive const and immutable qualifiers 6. ranges based on slices rather than pointer pairs

I think D failed to gain widespread traction for other reasons though: 1. The use of garbage collection. If you accept GC there are many other languages you can use. If you don't want GC the only realistic option was C++. Rust doesn't rely on GC. IIRC GC in D is optional in some way, but the story always felt murky to me and that always felt like a way of weaseling out of that problem - like if I actually started wri…

> I think D failed to gain widespread traction for other reasons though:

D's selling only proposition was providing C++11 features in a point in time between C++98 and C++11 when the C++ committee struggled to get a new standard out of the door.

Once C++11 was out, D's sales pitch was moot, and whatever wind it had in it's sail was lost and never recovered again.

It's interesting to note that Rust, in spite of all odds and also it's community, managed to put together a far more compelling sales pitch than D.

Re: Safe C++ proposal is not being continued

#192

Post by ranger_danger »

Yoric wrote: post #16
quotemstr wrote: post #11

Earlier quoted context omitted.

That's what the "Profiles" feature is. The problem is that any nontrivial real world program in a non-GC language needs non-owning reference types to perform well, and you can't express the rules for safe use of non-owning references without augmenting the language. People have tried. You need something more sophisticated than using smart pointers for everything. In the limit, smart pointers for everything is just ca…

> In the limit, smart pointers for everything is just called "Python". To be more precise, it's old Python. Recent versions of Python use a gc. > And I am being walked hands handcuffed behind my back, alongside everyone else, into the Rust world with its comparatively anemic proc macro shit because the C++ committee can't be bothered to care about memory safety. Out of curiosity (as someone working on static analysis…

To be even more precise:

> Reference counting is the primary mechanism of garbage collection, however, it doesn’t work when the references have cycles between them and for handling such cases it employs the GC.

Re: Safe C++ proposal is not being continued

#193

Post by kazinator »

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…

The first four letters of "culture" are certainly right.

Re: Safe C++ proposal is not being continued

#194

Post by vintagedave »

Voultapher wrote: post #126
vintagedave wrote: post #114

Earlier quoted context omitted.

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 (jus…

As much as the alternatives (profiles) don't solve the issue, Safe C++ (Circle) does have substantial issues as well. You need a separate and largely incompatible standard library, including containers. Generic code (templates) is largely left unsolved on a conceptual level so far. At this point incrementally replacing parts of your code with Rust - which has a mature ecosystem and tooling, remember if you want prova…

I get that, though I think different containers can be refactored well.

Replacing parts with an entirely different language is a whole other level compared to same language, modified standard library.

And I think a big reason Rust is winning is that it works, today. C++ doesn't. There is no other path other than to migrate to another language.

Re: Safe C++ proposal is not being continued

#195

Post by UltraSane »

zozbot234 wrote: post #67
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…

> So far I've always succeeded without using "unsafe" or indices, but it drags down productivity. There is a common perception that Rust is less productive than competing languages, but empirical research by Google and others has found this to be wrong. Rust just shifts the effort earlier in the development phase, where the costs are often orders of magnitude lower. You may spend a few hours struggling with the borro…

The biggest issue with Rust that I have found is that there are phase changes where making small changes to the code becomes impossible and you must completely redesign the program for it to work with the borrow checker.

Re: Safe C++ proposal is not being continued

#196

Post by burakemir »

lallysingh wrote: post #93

Call me stupid for asking, but what is "safe" here? I get the length-checked buffer copies and accesses, is there anything else? Less allowed type conversions?

There is an old definition of language safety which means "no untrapped execution errors". It is not the only way to define safety, but it is a good way that you can adapt to various kinds of x-safety, such as memory safety.

I have a little post that explains this using a few more words, if interested: https://burakemir.ch/post/memory-safety-the-missing-def/

Re: Safe C++ proposal is not being continued

#197

Post by Panzerschrek »

seanbax wrote: post #179
Panzerschrek wrote: post #97

The mentioned proposal isn't really that great. It basically tries to make C++ to Rust by blindly copying many its ideas. Many of them aren't strictly necessary to achieve safety in C++. There are different proposals for safety, which are way smaller and simpler than this one.

Which ideas aren't strictly necessary to achieve safety in C++?

Porting Rust enums and pattern matching isn't necessary (C++ already has std::variant).

Lifetime parameters aren't necessary, lifetime contracts may be implemented in a different and much easier way. This may be expressed in form of a function attribute, which may be calculated via constexpr code.

Special operators for borrowing just add more complexity. C++ already achieves same behavior by normal references (which may be mutable and non-mutable).

Introducing immutability by default isn't strictly necessary for achieving safety. C++ developers are already mostly fine writing "const" almost everywhere.

Re: Safe C++ proposal is not being continued

#198

Post by WalterBright »

IshKebab wrote: post #143
WalterBright wrote: post #123

Earlier quoted context omitted.

Using D does not require a garbage collector. You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations. D has a lot of very useful features. Memory safety features are just one aspect of it. > The awkward standard library schism. ??? Don't underestimate the backing of a large and powerful organization.

> You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations. Yes but people wanted a language where you can't use GC. > ??? "Which standard library should I use?" is not a question most languages have: https://stackoverflow.com/q/693672/265521 Surely... you were aware of this problem? Maybe I misunderstood the "???". > Don't underestimate the backing of a large a…

> Yes but people wanted a language where you can't use GC.

What do you think of C and C++ coming with extensive guides for best practices and what features to not use? Even so, D comes with an @nogc attribute which won't let you use the GC. Ironically, people complain that @nogc actually does not allow use of the GC. You can also use the -betterC compiler switch to not use the GC.

Interestingly, Compile Time Function Execution works great with the GC, as one needn't have to do backflips to allocate some memory.

Mozilla is orders of magnitude larger and more powerful than the D Language Foundation.

Re: Safe C++ proposal is not being continued

#199

Post by WalterBright »

fl0ki wrote: post #174
IshKebab wrote: post #143

Earlier quoted context omitted.

> You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations. Yes but people wanted a language where you can't use GC. > ??? "Which standard library should I use?" is not a question most languages have: https://stackoverflow.com/q/693672/265521 Surely... you were aware of this problem? Maybe I misunderstood the "???". > Don't underestimate the backing of a large a…

"The best thing about standard libraries is that there are so many to choose from"

D has only one.

Re: Safe C++ proposal is not being continued

#200

Post by purplesyringa »

Panzerschrek wrote: post #197
seanbax wrote: post #179

Earlier quoted context omitted.

Which ideas aren't strictly necessary to achieve safety in C++?

Porting Rust enums and pattern matching isn't necessary (C++ already has std::variant). Lifetime parameters aren't necessary, lifetime contracts may be implemented in a different and much easier way. This may be expressed in form of a function attribute, which may be calculated via constexpr code. Special operators for borrowing just add more complexity. C++ already achieves same behavior by normal references (which…

> Lifetime parameters aren't necessary, lifetime contracts may be implemented in a different and much easier way. This may be expressed in form of a function attribute, which may be calculated via constexpr code.

Wouldn't that just be slightly different syntax for the same idea? If you want to represent relationships like "the pointer in the field Struct::field_name within this argument is linked with the lifetime of the returned pointer" and you want them to be reusable across functions and contexts, isn't the most obvious way to write that a variant of

    struct Struct {
        char *'a field_name;
    };

    char *'a f(Struct& struct);

?
Post reply on HN