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

201–210 of 226 posts

Re: Safe C++ proposal is not being continued

#201

Post by seanbax »

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 are necessary for borrow checking. And you need a special operator for initiating a borrow. You need immutability by default, because mutability everywhere violates exclusivity.

Re: Safe C++ proposal is not being continued

#202

Post by maleldil »

m3047 wrote: post #187
maleldil wrote: post #177

Earlier quoted context omitted.

> Normally no one talks anymore about things like buffer overflows, use after free,... since years Some of the biggest vulnerabilities of recent years (e.g. Heartbleed) were out-of-bounds access. The most common vulnerability sources are things that are impossible in Rust, but cannot be fully solved via C++ static checkers.

Rust has unsafe, just like Java.

On the other hand, _all_ of C++ is unsafe.

Re: Safe C++ proposal is not being continued

#203

Post by x0nr8 »

seanbax wrote: post #157

I would have implemented profiles if profiles had a chance of working. But they will not ever work. I present many examples of why they fail here: https://www.circle-lang.org/draft-profiles.html People who say Profiles are a path forward, please address any of the points in this document.

Unrelated but are you back at the Big Green? Curious about what they have you working on.

Re: Safe C++ proposal is not being continued

#204

Post by coderedart »

jmull wrote: post #161
dwattttt wrote: post #83

Earlier quoted context omitted.

I imagine it's (implicitly?) referring to avoiding whole-of-program analysis. For example, given a declaration int* func(int* a); What's the relationship between the return value and the input? You can't know without diving into 'func' itself; they could be the same pointer or it could return a freshly allocated pointer, without getting into the even more esoteric options. Trying to solve this without recursively ana…

> avoiding whole-of-program analysis Why, though? Perhaps it's unfeasibly complex? But if that's the argument, then that's an argument that needs to be made. The paper sets out to refute the idea that C++ already has the information needed for safety analysis, but the examples throw away most of the information C++ does have, without explanation. I can't really take it seriously.

Local reasoning is the foundation of everything formal (this includes type systems) and anyone in the type-system-design space would know that. Graydon Hoare (ex-rust dev) wrote a post about it too (which links to another great without-boat's post in the very first line): https://graydon2.dreamwidth.org/312681.html

The entire point of having a static-type-system, is to enable local reasoning. Otherwise, we would just do whole program analysis on JS instead of inventing typescript.

Re: Safe C++ proposal is not being continued

#205

Post by quotemstr »

int_19h wrote: post #91
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…

> You need something more sophisticated than using smart pointers for everything. In the limit, smart pointers for everything is just called "Python". I don't see how that follows at all. What makes Python Python (and slow!) is dynamic dispatch everywhere down to the most primitive things. Refcounted smart pointers are a very minor thing in the big picture, which is why we've seen Python implementations without them…

> Jython, IronPython

Both of which have modern, concurrent, parallel, and generational garbage collectors.

Re: Safe C++ proposal is not being continued

#206

Post by dwattttt »

steveklabnik wrote: post #175
jmull wrote: post #161

Earlier quoted context omitted.

> avoiding whole-of-program analysis Why, though? Perhaps it's unfeasibly complex? But if that's the argument, then that's an argument that needs to be made. The paper sets out to refute the idea that C++ already has the information needed for safety analysis, but the examples throw away most of the information C++ does have, without explanation. I can't really take it seriously.

In general, there are three reasons to avoid whole program analysis: 1. Complexity. This manifests as compile times. It takes much longer. 2. Usability. Error messages are poor, because changes have nonlocal effects. 3. Stability. This is related to 2. Without requirements expressed in the signature, changes in the body change the API, meaning keeping APIs stable is much harder. There’s really a simple reason why it’…

It's not even required for the information to be present at link time; C/C++ doesn't require the pointer to always be owned or not-owned, it's valid for that to be decided by configuration loaded at runtime. Or for it to be decided at random.

Trying to establish proofs that the pointer is one way or the other can't work, because the pointer doesn't have to be only one or the other.

The fact that you then have to treat the pointer one way or the other is a problem; if you reduce the allowed programs so that the pointer must be one of the two that's a back-compat hazard. If you don't constrain it, you need to require additional information be carried somewhere to determine how to treat it.

If you do neither, you don't have the information needed to safely dispose of the pointer.

Re: Safe C++ proposal is not being continued

#207

Post by motorest »

WalterBright wrote: post #198
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…

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

> What do you think of C and C++ coming with extensive guides for best practices and what features to not use?

I feel that this is a disingenuous point and that you know better than this.

For example, the poster child of C++'s "don't use this feature" cliche are exceptions, and it's origins are primarily in Google's C++ stye guide.

https://google.github.io/styleguide/cppguide.html#Exceptions

If you cross-reference your claims with what Google's rationale was, you will be forced to admit your remark misrepresents the whole point.

You do not need to read too far to realize Google's point is that they have a huge stack of legacy code that is not exception-safe and not expected to be refactored, and introducing exceptions would lead their legacy code to break in ways that is not easy to remediate.

So Google had to make a call, and they decided to add the caveat that if your code is expected to be invoked by exception-free code, it should not throw exceptions.

Taken from the guide:

> Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

I wonder why you left this bit out.

If this is how you try to get D to shine, then you should know why it isn't.

Re: Safe C++ proposal is not being continued

#208

Post by Panzerschrek »

purplesyringa wrote: post #200
Panzerschrek wrote: post #197

Earlier quoted context omitted.

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…

Using tags like 'a may work, but it's not flexible in templated code. A better approach is to allow calculating such tags in compilation time. But in such way you don't even need named tags, you can just use pairs of integers, like reference #n of param #m.

Re: Safe C++ proposal is not being continued

#209

Post by Panzerschrek »

seanbax wrote: post #201
Panzerschrek wrote: post #197

Earlier quoted context omitted.

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 are necessary for borrow checking. And you need a special operator for initiating a borrow. You need immutability by default, because mutability everywhere violates exclusivity.

You don't need special operator for initializing borrow. Calling a function like Foo(a) will initialize such borrow, if function parameter is mutable reference. The same is for creating local mutable reference.

Mutability by default is good, but it's not strictly necessary. I repeat, you can just write "const" everywhere manually, except places, where mutation is needed.

Re: Safe C++ proposal is not being continued

#210

Post by WalterBright »

motorest wrote: post #207
WalterBright wrote: post #198

Earlier quoted context omitted.

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

> What do you think of C and C++ coming with extensive guides for best practices and what features to not use? I feel that this is a disingenuous point and that you know better than this. For example, the poster child of C++'s "don't use this feature" cliche are exceptions, and it's origins are primarily in Google's C++ stye guide. https://google.github.io/styleguide/cppguide.html#Exceptions If you cross-reference yo…

C++ has a lot of features which are not best practices. For example, you're not supposed to use the builtin arrays anymore, in favor of vector.

Google's guide is not the only one. There are the Scott Meyers series "Effective C++" with things like "declare destructors virtual in polymorphic base classes". D's destructors in polymorphic are always virtual.

This brings up another issue with C++ - conflation of polymorphic structs with non-polymorphic structs. The former should always be passed by reference, the latter maybe or maybe not. What C++ should have done is what D does - structs are for aggregation, classes are for OOP. The fundamental differences are enforced.

How does one enforce not passing a polymorphic object by value in C++? Some googling of the topic results in variations on "don't do that".

Post reply on HN