C++

1978 readers

6 users here now

The center for all discussion and news regarding C++.

Rules

Respect instance rules.
Don't be a jerk.
Please keep all posts related to C++.

founded 2 years ago

MODERATORS

[email protected]

The empire of C++ strikes back with Safe C++ blueprint (www.theregister.com)

submitted 7 months ago* (last edited 7 months ago) by [email protected] to c/[email protected]

36 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 13 points 7 months ago* (last edited 7 months ago) (24 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] 14 points 7 months ago (7 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 7 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 7 months ago (1 children)

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

[–] [email protected] 7 points 7 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 7 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 7 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 7 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 5 months ago

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

load more comments (5 replies)

load more comments (21 replies)