The empire of C++ strikes back with Safe C++ blueprint : cpp

[–] [email protected] 13 points 6 months ago* (last edited 6 months ago) (4 children)

From the article.

Josh Aas, co-founder and executive director of the Internet Security Research Group (ISRG), which oversees a memory safety initiative called Prossimo, last year told The Register that while it's theoretically possible to write memory-safe C++, that's not happening in real-world scenarios because C++ was not designed from the ground up for memory safety.

That baseless claim doesn't pass the smell check. Just because a feature was not rolled out in the mid-90s would that mean that it's not available today? Utter nonsense.

If your paycheck is highly dependent on pushing a specific tool, of course you have a vested interest in diving head-first in a denial pool.

But cargo cult mentality is here to stay.

[–] [email protected] 16 points 6 months ago (1 children)

I think, the idea was along the lines of "because C++ was not memory-safe, and it has to stay compatible with how it was, there are still a lot of ways to not write memory-safely"

This makes sense, there are memory-safely features available but there are a lot of programmers that will never willingly use that features, because the olden ways are surely better

Other than that, I agree, when you're paid to fix an unfixable problem you will probably claim something like that and advocate for your solution being the only one that solves this

[–] [email protected] 3 points 6 months ago (1 children)

there are a lot of programmers that will never willingly use that features, because the olden ways are surely better

Found the rust shill.

[–] [email protected] 3 points 6 months ago (3 children)

If you want everyone to stop trying to shove Rust everywhere, just use smart pointers more. I may somehow get over Rust not replacing every other language if those languages will be safe

[–] [email protected] 14 points 6 months ago (1 children)

Just because a feature was not rolled out in the mid-90s would that mean that it’s not available today?

Adding a feature is one thing, C++ has added a lot of memory safety features over the years. The problem with C++ is it still allows a lot of unsafe ways of working with memory that previous projects used and people still use now. Removing support for these features will break existing code and piss a lot of people off in the process. It is not about adding new features, but removing the unsafe existing features that they are talking about here.

[–] [email protected] 2 points 6 months ago (1 children)

The problem with C++ is it still allows a lot of unsafe ways of working with memory that previous projects used and people still use now.

Why do you think this is a problem? We have a tool that gives everyone the freedom to manage resources the way it suits their own needs. It even went as far as explicitly supporting garbage collectors right up to C++23. Some frameworks adopted and enforced their own memory management systems, such as Qt.

Tell me, exactly why do you think this is a problem?

[–] [email protected] 14 points 6 months ago (1 children)

All the use after free and buffer overflow bugs that plague our key infrastructure.

[–] [email protected] 7 points 6 months ago (2 children)

It's not just that. Debugging segfaults and UB can be an absolute nightmare.

The C++ committee still haven't learnt their lesson. I recently learnt about C++20 coroutines, which are pretty neat, if complex (there are pretty much no good learning resources about them). However they are still putting unnecessary UB footguns in it.

[–] [email protected] 4 points 6 months ago (1 children)

Reminds me of how I found some safety measures to be in China some years back, basically those were signs saying "plz don't fall to your death, if you do it's your fault"

[–] [email protected] 1 points 5 months ago (1 children)

At least it's not like Russia, where it's “plz don’t fall to your death, if you do it’s our fault”...

[–] [email protected] 2 points 5 months ago

I thought a lot of places are like that, that's why we get all the fences and such 🤔

[–] [email protected] 1 points 4 months ago

Maybe a "pragma strict" where every deprecated is an error and not a warning?

[–] [email protected] 11 points 6 months ago (1 children)

If you could reliably write memory safe code in C++, why do devs put memory safety issues intontheir code bases then?

Even highly paid (and probably skilled) devs in the IT industry manage to mess that up pretty regularly. Even if it was: devs using memory safe languages make much fewer mistakes wrt. managing memory... so that tooling does seem to help them at least more than the C++ tooling helps the C++ devs.

[–] [email protected] 5 points 6 months ago (1 children)

If you could reliably write memory safe code in C++, why do devs put memory safety issues intontheir code bases then?

That's a question you can ask to the guys promoting the adoption of languages marketed based on memory safety arguments. I mean, even Rust has a fair share of CVEs whose root cause is unsafe memory management.

[–] [email protected] 3 points 6 months ago (1 children)

No it doesn't, that's bullshit.

[–] [email protected] 3 points 6 months ago (1 children)

Well, there is cve-rs, just sayin'

[–] [email protected] 3 points 6 months ago

The fact that rustc has bugs (which is what cve-rs exploit) doesn't invalidate that rust the language is memory safe.

[–] [email protected] 7 points 6 months ago (2 children)

The only (arguably*) baseless claim in that quote is this part:

it’s theoretically possible to write memory-safe C++

Maybe try to write more humbly and less fanatically, since you don't seem to be that knowledgable about anything (experienced in other threads too).

* It's "theoretically possible" to write memory-safe assembly if we bend contextual meanings enough.

[–] [email protected] 3 points 6 months ago* (last edited 6 months ago) (1 children)

The only (arguably*) baseless claim in that quote is this part:

You do understand you're making that claim on the post discussing the proposal of Safe C++ ?

And to underline the absurdity of your claim, would you argue that it's impossible to write a"hello, world" program in C++ that's not memory-safe? From that point onward, what would it take to make it violate any memory constraints? Are those things avoidable? Think about it for a second before saying nonsense about impossibilities.

[–] [email protected] 8 points 6 months ago

C++ offers no guaranteed memory safety.
A fictional safe C++ that would inevitably break backwards compatibility might as well be called Noel++, because it's not the same language anymore.
If that proposal ever gets implemented (it won't), neither the promise of guaranteed memory safety will hold up, nor any big C++ project will adopt it. Big projects don't adopt the (rollingly defined) so-called modern C++ already, and that is something that is a part of the language proper, standardized, and available via multiple implementations.

would you argue that it’s impossible to write a"hello, world" program in C++

bent as expected

This proposal is just a part of a damage control campaign. No (supposedly doable) implementation will ever see the light of day. Ping me when this is proven wrong.

[+] [email protected] 12 points 6 months ago* (last edited 3 months ago) (2 children)

[deleted]

[–] [email protected] 9 points 6 months ago

I heavily disagree. C++ has a lot of problems but it's flexibility is not one of them.

Imo the biggest problem with C++ is that there are a dozens ways of doing the same thing. The std lib is not general and fast enough for everyone. Therefore it's not even "standard" .

I have seen many conferences of a proposed "cpp2" like syntax that breaks abi but imo it's the best way forward.

[–] [email protected] 4 points 6 months ago (2 children)

Rust still allows people to do (basically) whatever they want via unsafe blocks.

[–] [email protected] 9 points 6 months ago (2 children)

Yeah but I have written a lot of Rust and I have yet to use a single unsafe block.

Saying "but.. unsafe!" is like saying Python isn't memory safe because it has ctypes, or Go isn't memory safe because of its unsafe package.

[–] [email protected] 4 points 6 months ago (1 children)

You don't have to use unsafe C++ functions either

C++ is technically safe if you follow best practices

The issue, to me, is that people learn older versions of the language first, and aren't aware of the better ways of doing stuff.

IMO people should learn the latest C++ version first, and only look at the older types of implementation when they come across them

[–] [email protected] 2 points 6 months ago (1 children)

C++ is technically safe if you follow best practices

Yeah but it's virtually impossible to reliably follow best practices. The compiler won't tell you when you're invoking UB and there is a lot of potential UB in C++.

So in practice it is not at all safe.

[–] [email protected] 4 points 6 months ago

I agree

I was only adding my opinion (that people should try to always use the latest version of C++, which is inherently safer, but still not 100% safe)

[–] [email protected] 1 points 6 months ago

See my reply to funtrek's reply.

[–] [email protected] 6 points 6 months ago (1 children)

babe wake up c++++ just dropped

[–] [email protected] 4 points 6 months ago

C# is C++ and another ++ on top of the existing ++

[–] [email protected] 5 points 6 months ago (1 children)

I don't understand why this is called a "subset", while clearly containing new syntax

A subset would be understood by older compilers, this is a superset

[–] [email protected] 7 points 6 months ago* (last edited 6 months ago)

The goal of this proposal is to advance a superset of C++ with a rigorously safe subset.

The subset is of the proposed syntax superset. Reason being because the superset also contains explicitly unsafe syntax similar to rust.

[–] [email protected] 3 points 6 months ago* (last edited 6 months ago)

While the summary + interview The Register did was decent, when you read the actual paper, the proposal is way more interesting.

Not a fan of mut instead of just plain mutable, though.

Also I sure hope the compiler messages for this feature won't be like the circle examples in the proposal in the end.

C++

Rules