C++ Committee Prioritizes 'Profiles' Over Rust-Style Safety Model Proposal

Long-time Slashdot reader robinsrowe shared this report from the Register: The C++ standards committee abandoned a detailed proposal to create a rigorously safe subset of the language, according to the proposal's co-author, despite continuing anxiety about memory safety. "The Safety and Security working group voted to prioritize Profiles over Safe C++. Ask the Profiles people for an update. Safe C++ is not being continued," Sean Baxter, author of the cutting-edge Circle C++ compiler, commented in June this year. The topic came up as developers like Simone Bellavia noted the anniversary of the proposal and discovered a decision had been made on Safe C++.

One year ago, Baxter told The Reg that the project would enable C++ developers to get the memory safety of Rust, but without having to learn a new language. "Safe C++ prevents users from writing unsound code," he said. "This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety." Safe C++ would enable incremental migration of code, since it only applies to code in the safe context. Existing unsafe code would run as before.

Even the matter of whether the proposal has been abandoned is not clear-cut. Erich Keane, C++ committee member and co-chair of the C++ Evolution Working Group (EWG), said that Baxter's proposal "got a vote of encouragement where roughly 1/2 (20/45) of the people encouraged Sean's paper, and 30/45 encouraged work on profiles (with 6 neutral)... Sean is completely welcome to continue the effort, and many in the committee would love to see him make further effort on standardizing it."

In response, Baxter said: "The Rust safety model is unpopular with the committee. Further work on my end won't change that. Profiles won the argument." He added that the language evolution principles adopted by the EWG include the statement that "we should avoid requiring a safe or pure function annotation that has the semantics that a safe or pure function can only call other safe or pure functions." This, he said, is an "irreconcilable design disagreement...."

Re: A comittee of morons

[Z00L00K]

I'd consider to avoid C/C++ for anything but the most time critical functionalities.

There is already a safe subset of C++

[EMB Numbers]

There is already a safe subset of C++ as demonstrated by safety critical code including code in aircraft cockpits. Standards like Motor Industry Software Reliability Association (MISRA) exist for C++. Such standards generally include rules prohibiting dynamic resource allocation at run time. All threads and all memory must be allocated are compile time or at initialization time. Of course, following these rules means that 90% of the Standard Template Library (STL) cannot be used. All memory accesses must be bounds checked, etc.

I live in the world of MISRA C++. It is surprisingly easy to live with the constraints. I work in large code bases that do not contain a single "new" or "delete". The problem is that most programmers are unaware of the risks that standards like MISRA try to mitigate. Programmers are poorly trained about memory safety and dynamic resource allocation. In my opinion, languages like Rust exist to put ignorant programmers in straight jackets for their own good. Java tried to do the same thing with "managed" code. The real solution is to cultivate less ignorant programming programmers.

With all of the above said, there are two different worlds of programming: Closed World, and Open World. This is not a reference to Opensource. This is about he types of problems to be solved.

Closed world is like ethe transmission in a traditional car. All of the parts are created to exacting standards and fit together only one way. Transmissions are not user serviceable. Any modifications to the transmission likely degrade its functionality. All of the parts were present at the factory (compile time), and none will ever be added or removed (no dynamic resource allocation).

Open World problems are like the trunk of the car. Nobody at the factory can predict everything that might be stored in the trunk. Items are added and removed from the trunk all the time. Limitations to the contents of the trunk make the trunk less useful. Databases and authoring tools like Word or Blender and most user interfaces with plugins etc. are exist in the Open World. Limitations to the number of pages in your document or the number of tables in your database make the documents and databases less useful.

C++ is used to solve both Closed World and Open World problems. C++ id the largest most complex programming language ever conceived in part because it tries to be everything for everyone. This is why "Profiles" are so important. If I understand correctly, "Profiles" identify subsets of teh languages and force programmers to live within the selected subset. In reality, this is the only way C++ programmers survive today. Everybody chooses a subset of the language. Unfortunately, even team chooses a different subset, so when components are integrated from multiple teams/suppliers, the union of the subsets produces a larger subset. Since and repeat until you are using the entire language again.

By the way, tools exist to audit C++ code for things like MISRA compliance. Adding such tools to the language itself may not be particularly valuable...

Re:

[nadass]

This comparative metaphor makes sense. But it seems the C++ EWG is hoping to contain bad code (put limits on the trunk's abilities) rather than creating a culture of good code (teaching drivers efficient usage of the trunk).

In the end, EWG doesn't want to nurture a culture of safe code; they want safe code to happen by accident. Wishful thinking indeed...

Re:There is already a safe subset of C++

[Waffle Iron]

languages like Rust exist to put ignorant programmers in straight jackets for their own good

Are you seriously trying to suggest that never allocating memory is not also a "straight jacket"?

You seem to be saying that a currently existing bowdlerized version C++ is safe for close-world problems. Possibly so, but that still leaves C++ unsuitable for open-world problems. That makes C++ only suitable for niche applications. Why learn it?

If you just use Rust or any other memory safe language, you won't have to worry about what kind of "world" you're writing for, or about choosing from a range of increasingly dangerous "profiles".

Re:

[arglebargle_xiv]

In the sort of places where MISRA and similar coding guides apply, yes, never allocating memory is expected, because once dynamic allocation exists you can't guarantee that you won't die with an out-of-memory error and similarly can't guarantee any time bounds on how long an alloc and dealloc will take. That doesn't mean you can't have dynamically sized memory blocks, they just have to be drawn from a fixed-size arena and in a manner that guarantees constant-time performance, for example with a high-water-

Re:

[swillden]

In the sort of places where MISRA and similar coding guides apply, yes, never allocating memory is expected, because once dynamic allocation exists you can't guarantee that you won't die with an out-of-memory error and similarly can't guarantee any time bounds on how long an alloc and dealloc will take.

Sure, so C++ is safe as long as it's used in a way that makes it incredibly painful. Sounds good. Let's just require all C++ code everywhere to be written that way. Rust usage will skyrocket overnight.

Re:

[Pinky's Brain]

That is no longer a system programming language.

Re:There is already a safe subset of C++

[sinij]

The real solution is to cultivate less ignorant programming programmers.

No, this is utopian solution. The real solution is to have programming tools that can allow average programmer to produce safe compiled code.

Re:

[phantomfive]

The real solution is to have programming tools that can allow average programmer to produce safe compiled code.

That is not Utopian, according to you?

Re:

[gweihir]

The real solution is to cultivate less ignorant programming programmers.

No, this is utopian solution. The real solution is to have programming tools that can allow average programmer to produce safe compiled code.

That will never work. It would require AGI and that is not even on the very distant horizon. In fact, there are good arguments that it may well be impossible to create. The reality is that bad coders (the vast majority) just screw up the program logic if they are prevented from making lower-level errors.

Re:

[Anonymous Coward]

That will never work. It would require AGI and that is not even on the very distant horizon.

That's an interesting claim, given rustc already does it.

By your logic, we don't need seat belts in cars

[Somervillain]

Programmers are poorly trained about memory safety and dynamic resource allocation. In my opinion, languages like Rust exist to put ignorant programmers in straight jackets for their own good. Java tried to do the same thing with "managed" code. The real solution is to cultivate less ignorant programming programmers.

The problem with your comment is that the most destructive exploits were introduced by well trained programmers who knew what they're doing. And with security, you can do a billion things right and one stupid mistake from someone else and your system is hacked. This is akin to seat belts. I've never needed one. I've just taken the strategy of never being in an accident for the 30 years I've been driving. However, I am not stupid enough to think I don't need a seat belt. Even if I never make a mistake,

Re:

[phantomfive]

The problem with your comment is that the most destructive exploits were introduced by well trained programmers who knew what they're doing.

Which exploits are you talking about here?

What I'm saying is, you're a liar.

So MS/Google/Appl programmers aren't well trained?

[Somervillain]

The problem with your comment is that the most destructive exploits were introduced by well trained programmers who knew what they're doing.

Which exploits are you talking about here? What I'm saying is, you're a liar.

I am talking about every exploit that ever surfaced from a commercial company that hires expensive programmers who are well educated and generally knew what they're doing. "Knowing what you're doing" doesn't mean you don't make mistakes and they obviously made one. However, MS has introduced hundreds. Apple, Google, everyone has exploits and mistakes and viruses and memory bugs.

While shitting on MS is a long-standing /. pastime, I know for a fact MS, prides themselves in hiring top developers. They

Re:

[phantomfive]

That's what I thought: you are making things up and wishing they were true. Worst kind of idiot.

Re:

[kertaamo]

Ah, I see, not you are not only saying someone is a lier but you are also calling them an idiot. What a wonderful person you are.

As it happens there is plenty of evidence, published by the likes of Google and MS them selves that their highly skilled, trained and experienced staff has produces many security and other problems by mistakes in memory usage.

Meanwhile you are making the absurd claim that sufficiently skilled, trained and experience programmers never make such mistakes.

You really should think abou

Re:

[arglebargle_xiv]

I would ignore him, he's a troll who has no idea who he's arguing with.

Re:

[gweihir]

You are mistaken. The problem is that that "top developer" does not mean "competent and careful developer that knows what they are doing" to most of the industry and even more so to MicroShit. It means "can produce code that works fast, does what the boss wants and who cares about safety and security".

So this will somehow change in the future?

[Somervillain]

You are mistaken. The problem is that that "top developer" does not mean "competent and careful developer that knows what they are doing" to most of the industry and even more so to MicroShit. It means "can produce code that works fast, does what the boss wants and who cares about safety and security".

OK. Yeah, but who has shipped perfect code? Will this ever change? Maybe MS sucks? Well, everyone else has vulnerabilities as well...just not as many...so is that going to change? It's been 40 years since C++ came out.

I write business code in a memory safe language, so I am peripheral to this debate, but the way I see it...we can use memory-safe languages or technology...whatever the C++ folks come up with or Rust or any other....or we can continue doing what we're doing and pretending C++ is not a

Re:

[kertaamo]

Did it ever occur to you that calling someone a liar is a serious accusation. That you are basically stating that they said something untrue on purpose for some malignant purpose. It's a terrible way to respond, unnecessarily aggressive . Has it ever occurred to you that:
1) They may be very well intentioned but just mistaken.
2) That what they say is partially correct. After all nothing is usually so black and white.
3) That it may actually be you that is mistaken.

So while asking for more evidence with "Which

Re:

[arglebargle_xiv]

You left out:

4) He's a troll who will argue anything with anyone just for the sake of it.

Which is most likely the case here.

Re:

[gweihir]

Programmers are poorly trained about memory safety and dynamic resource allocation. In my opinion, languages like Rust exist to put ignorant programmers in straight jackets for their own good. Java tried to do the same thing with "managed" code. The real solution is to cultivate less ignorant programming programmers.

The problem with your comment is that the most destructive exploits were introduced by well trained programmers who knew what they're doing.

I disagree. This is just something you are hallucinating.

Re:

[jd]

Ish.

I would not trust C++ for safety-critical work as MISRA can only limit features, it can't add support for contracts.

There have been other dialects of C++ - Aspect-Oriented C++ and Feature-Oriented C++ being the two that I monitored closely. You can't really do either by using subsetting, regardless of mechanism.

IMHO, it might be easier to reverse the problem. Instead of having specific subsets for specific tasks, where you drill down to the subset you want, have specific subsets for specific mechanisms

Re:

[gweihir]

I can add contracts manually. I have done so in some critical applications with excellent success. But most coders do not even know what a "contract" is.

Re:

[John Allsup]

If you put programmers inside the Rust straitjacket until they understand the nature of it and the reasoning behind it, and then let them use C++, they'll probably be conditioned to be memory safe. Rust forces you to do what you should be doing anyway in a language like C++. And Rust can compile-time check that stuff.

I'm very much a 'do the experiment' person when it comes to C++ vs Rust. There is plenty of will to write stuff in Rust, so the rest of us can grab popcorn, watch, and then observe the outcomes

Re:

[EMB Numbers]

MISRA is absolutely a coding standard if it is adopted as one. There are multiple MISRA rule checkers that enforce the rules as coding standards.

MISRA makes no guarantees. MISRA mitigates several problems. There are copious other issues like determinism (which is generally impossible with dynamic resource allocations) and plain old logic errors. There is no shortage of ways a program can be wrong or broken. Rust won't save programmers from logic errors either. Using MISRA as a coding standard means there wi

Re:

[arglebargle_xiv]

You're arguing with a Rust Flake there, I doubt it's worth the effort.

This would have actually been quite an interesting discussion topic if it wasn't for the 50% troll content.

Re:

[tender-matser]

All threads and all memory must be allocated are compile time or at initialization time.
[...]
I work in large code bases that do not contain a single "new" or "delete".

Quick question: are you still allowed to call function recursively?

If yes, then all those restrictions are pointless cargo-cult posturing. You could just as well override 'new' and limit how much memory (and where) it could allocate and obtain the same effect.

If not, you should stop using C++. There is no need to learn how to manage all that c

Re:

[gweihir]

Programmers are poorly trained about memory safety and dynamic resource allocation. In my opinion, languages like Rust exist to put ignorant programmers in straight jackets for their own good. Java tried to do the same thing with "managed" code. The real solution is to cultivate less ignorant programming programmers.

Indeed. This is not a language problem. This is a coder problem. You can write safe and secure code in any language. You just need to know what you are doing and when to be careful. Most "programmers" do not seem to have that skill. And hence "memory safety" is not actually the problem. Bad programmers can screw up safety and security in any language and that does include Rust and other "straight jacket" attempts. Actual skill and insight can only be replaced with more of the same. Unless the industry final

Re:

[kertaamo]

You are arguing that it's not. language problem, that all we need is perfect programers. Fine, but consider:

1) If we only had those mythical perfect programmers that never made memory safety errors in C++ then they would be following all the same rules that the Rust language imposes. Ergo it would not be any problem for them to use Rust instead.

2) Such wonderful programers would be expected to appreciate that the compiler checks everything for them. That saves them. from al the tedious mental effort of doin

Re: There is already a safe subset of C++

[hjf]

I particularly hate the elitism of the "perfect programmer" crowd. most of us are out there writing shitty CRUDs in the language of the day.

and the thing we always forget when we get such comments is that most of the time, issues with bad code and layers upon layers of crap, come from the business requirements.

software development is often criticized for lack of formality . but no one ever seriously starts building a house thinking of "refactoring" it into a skyscraper in the future. but with software devel

Re: There is already a safe subset of C++

[simlox]

MISRA is for ultra embedded where you know all resource requirements up front. In the cloud it would be very odd to restart with new pre-allocated stuff when you get more users. In embedded systems you pre-allocate things like ethernet packages, but you still need the logic of freeing them back to the pool. This can go wrong as easily as malloc/free. Rust, on the other hand, makes you handle references safely and calculates the problem of freeing resources for you. That is much more important than just not

Re:

[drinkypoo]

Closed world is like ethe transmission in a traditional car. All of the parts are created to exacting standards and fit together only one way. Transmissions are not user serviceable. Any modifications to the transmission likely degrade its functionality.

People can and do service their own transmissions, in particular doing a fluid and filter change is generally a pretty easy job. There are also modifications and upgrades to transmissions. You can buy "built" transmissions which include heavy duty parts which can handle larger power, torque, and/or shock loads than stock ones. There are "kits" of aftermarket parts which either address wear over time or even correct design deficiencies like either lazy or excessive engagement of clutches.

It was good but not great.

[Gravis Zero]

Before everyone gets their panties in a wad, while the Rust-style draft claims it "can’t break existing code", existing code also can't use it without breaking. Effectively, only code seeking to be safe would be use the features and I think that's what the C++ committee didn't like. It means all old code would have be revised which would result in a huge amount of code debt.

The "Profiles" approach seems more directed toward compilers finding existing issues in codebases which means all code will benefit and can quickly be fixed. There is far less code debt in this approach and the severity could be an reduced to compile-time warnings which makes migration much easier.

Re:

[nadass]

This implies the different approaches are like building a house with a safe and solid foundation, or patchworking a foundation with copious amounts of duct tape.

And in this vein, the C++ EWG prefers the duct tape approach... because laying new foundations in a well-regulated manner is hard, or rather, presents an "irreconcilable design disagreement...."

Taking a step back, the EWG (like all corporate programmers) are taking the path of least resistance ("what checks the box yet requires the least amoun

Hold up, friend.

[Gravis Zero]

You should look at the Rust-style draft because you have to manually enable it for every part of code that you want to be safe. You can totally ignore and just not use it. It's not the "solid foundation" you seem to think it is.

Re:

[tlhIngan]

This implies the different approaches are like building a house with a safe and solid foundation, or patchworking a foundation with copious amounts of duct tape.

And in this vein, the C++ EWG prefers the duct tape approach... because laying new foundations in a well-regulated manner is hard, or rather, presents an "irreconcilable design disagreement...."

Taking a step back, the EWG (like all corporate programmers) are taking the path of least resistance ("what checks the box yet requires the least amount of e

Re: It was good but not great.

[BytePusher]

It's also common for drafts to miss one or more cycles until there's a strong consensus. If there's a lot of controversy, then they aren't going to approve the draft. The committee doesn't want to have to replace the memory safety model with a new model and syntax in the future after thousands of companies and projects locked into the wrong model.

Zzzz

[fluffernutter]

Wake me up when Qt is memory safe.

Huh?

[Gravis Zero]

Qt's memory management is entirely based on using shared pointers. Honestly, it's kinda hard to screw up with Qt, like you have to go out of your way to screw up. i mean, other than failing to specify a parent object, how are you having memory issues in Qt?

Re: Huh?

[t_hunger]

I have hunted my fair share of core dumps in Qt code. Each one is a memory safety fail... it is, just like the rest of C++ not memory safe.

I find it funny that so many C++ devs seem to think using smart pointers means you are memory safe. It does not, there is so much more needed... check what the "safe C++" proposal set out to change, that's what you need tomdo to make C++ memory safe using the approach rust took. It includes fun stuff like new reference semantics, destructive moves and a new standard libr

Re:

[Gravis Zero]

Each one is a memory safety fail... it is, just like the rest of C++ not memory safe.

Like I said, you have to go out of your way to screw up. I never claimed it was perfect, only that you have to do something particularly dumb to break it. There is always going to be idiots in the ER because they used a tool the wrong way.

I find it funny that so many C++ devs seem to think using smart pointers means you are memory safe.

Safer, yes. Perfectly safe, no. When you build a fool-proof system then someone will build a better fool.

check what the "safe C++" proposal set out to change

I did. I even explained why it wasn't chosen. [slashdot.org] It's no panacea and as someone else pointed out [slashdot.org], safe subsets of C++ exist.

Re:

[fluffernutter]

You are referring to knowing the difference between shared pointers and unique pointers. That's the only way to screw it up. Yes, if you confuse a unique pointer for a shared pointer you screw it up. But if you don't know that one fact then you have no business coding C++ at all, especially since it is usually just a matter of sticking to using shared pointers all the time.

Re: Keep rust in rust

[t_hunger]

There is increasing pressure on companies to take responsibility for their software products. This includes preasure to move towards memory safe languages. This exercise is about getting C++ of the governments naughty lists, so that people can continue to use C++ without extra regulatory overhead and too much risk to the company.

Rust is just a working example of a language with similar performance to C++, whise approach could be copied. The committee opted to not do that and go for something that does not m

Do it yourself

[allo]

You don't need the language to enforce memory safety to program memory-safe. The most important thing is, for example, to never touch raw pointers. C++ makes it very easy to avoid this. Rust forces you to avoid it, but just because C++ gives you the loaded gun, it doesn't mean you have to use it. In particular not on your own foot.

Re:

[HiThere]

You oversimplify. I despise Rust, but it does address real problems. (I'm not sure how well, because I won't use it.) I'm thinking of thinks like deadlock, livelock, etc. As someone above pointed out, there are lots of applications that don't need to deal with that, and subsets can work for them. (The above poster worked in a domain where all memory could be pre-allocated.)

Rust felt like programming with one hand tied behind my back. So I dropped it. Only one reference to a given item it just too res

Re:

[SoftwareArtist]

I don't know of a better language than Rust for the specific case it's designed for: performance critical code. It's for when you want your code to run as fast as it possibly can, and you're willing to work harder for it. I don't know of any other language that can do that without sacrificing memory safety.

If you don't mind sacrificing a little speed, lots of languages provide memory safety with a lot less work. For most projects, that's the right choice. When you care about every last bit of speed, tho

Re:

[phantomfive]

I don't know of a better language than Rust for the specific case it's designed for: performance critical code.

That's because you don't know how to use a search engine and look at benchmarks.

https://benchmarksgame-team.pa... [debian.net]

Seriously, think before you post.

Re:

[SoftwareArtist]

I'm not sure what you think that's showing, but I'm pretty sure you didn't understand it. The three fastest languages on that site are C, C++, and Rust. There's a substantial gap between them and all other languages. Of those three, Rust is the only one with memory safety. Which was exactly what I said.

Of course, any experience programmer will tell you that microbenchmarks are not very useful. They don't give a good picture of what the performance of real programs is likely to be.

Re:

[phantomfive]

If you want performance, you choose C. That's what the data shows.

People like you don't want to use Rust, they want other people to use Rust.

Re:

[allo]

Many want to use rust. Look at how people rewrite all the standard utilities and some Linux distributions even adopt the new versions instead of the version that works fast and stable since more than three decades. Sure, no memory error, but what other bugs does a one year old rust version have, which a 30 year old C version fixed 25 years ago?

Re:Do it yourself

[Waffle Iron]

You don't need the language to enforce memory safety to program memory-safe. The most important thing is, for example, to never touch raw pointers. C++ makes it very easy to avoid this. Rust forces you to avoid it, but just because C++ gives you the loaded gun, it doesn't mean you have to use it. In particular not on your own foot.

That is a dangerous misconception. You don't need to use any pointers to get memory errors in C++:

#include <stdio.h>
#include <vector>
 
int main() {
    std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9};
    for (auto i : v) {
        if (i % 2 == 0) {
            v.push_back(i + 10);
        }
        printf("%d\n", i);
    }
 
    return 0;
}
 
$ g++ -Wall -pedantic t.cpp
$ echo $?
0
$ ./a.out
 
1
2
-947527061
1600570778
5
6
7
8
9

Re:

[EMB Numbers]

Nobody said the Standard Template Library (STL) wasn't a monstrosity :). The "rules" of mutable collections in STL state that collections may not be mutated while being iterated.

Note: The free Cppcheck that should be part of every C++ build system states:

~/Desktop/bug/bug/build $ cppcheck ../main.cpp
Checking ../main.cpp ... ../main.cpp:8:15: error: Calling 'push_back' while iterating the container is invalid. [invalidContainerLoop]

Re:Do it yourself

[Waffle Iron]

The "rules" of mutable collections in STL state that collections may not be mutated while being iterated.

Nope. If I had used st::list instead of std::vector, it would have been perfectly fine and officially supported. (Assuming I changed "i+10" to "i+11" in order to make the algorithm actually terminate, although that change wouldn't affect the vector crash.).

The problem is that there are dozens of different rules you have to remember to apply to the different types of lists and iterators. And that's only talking about that one topic. There are hundreds of other rules covering a multitude of language aspects that you have to mentally apply against every single line of code you write, many of which can potentially cause memory corruption.

Re:

[EMB Numbers]

So don't use STL and do use clang-tidy and Cppcheck and flaw finder and Sonarqube. All but the last are free. Cppcheck apparently knows "hundreds of other rules covering a multitude of language aspects" so you don't "have to mentally apply against every single line of code you write."

Re:Do it yourself

[Waffle Iron]

So don't use STL

Indeed, No True Scotsman would use STL with C++.

clang-tidy and Cppcheck and flaw finder and Sonarqube

The last job I had where I had to use C/C++, we automatically ran an expensive static analysis tool every time we checked in code. I'd estimate that it only found about half of the potential segfaults, and it made up for that by finding twice as many false positives.

Re:

[swillden]

Cppcheck apparently knows "hundreds of other rules covering a multitude of language aspects" so you don't "have to mentally apply against every single line of code you write."

Cppcheck doesn't flag anything in Waffle Iron's example.

It also doesn't find anything wrong with:

std::vector<int> vec = {1, 2, 3, 4, 5};
auto it = vec.begin();
vec.push_back(6);
std::cout << *it << std::endl;

Which is another common example of how you can write memory errors without using C++ pointers.

Re:

[bsolar]

The "rules" of mutable collections in STL state that collections may not be mutated while being iterated.

That's pretty common knowledge for an experienced programmer, but still something the programmer needs to know in a language like C++ to avoid writing unsafe code. Even using a static analysis tool is something the developer need to know and actively pursue.

The contrast is with languages that attempt to prevent even the unwary from writing unsafe code.

Re:

[Bu11etmagnet]

- Doctor, doctor, it hurts when I do this!
- Don't do it, then.

Re:

[gweihir]

There are good reasons to touch raw pointers in some cases. The actual thing is to be very careful when you do it and really understand what you are doing and what risks you are taking. Most "coders" cannot do that. And hence the mess we currently have. It is entirely a skill and education issue, not a language issue. It is also a management issue in that the wrong people get hired. Add normal engineering liability (like all _other_ engineering field have) and the problem will go away. But so will quite a f

Re:

[allo]

There are reasons for unsafe things, that's why even rust has unsafe blocks. The question is, if you cannot avoid it for 99% of your code and if the usual programmer of a programming language avoids it. My point is, that C++ used correctly is almost memory safe. Just don't use tutorials that are older than ten years. Much happened since then.

Re:

[gweihir]

No. What Rust calls "unsafe" is essentially a lie. You can still write blatantly unsafe code in Rust, it is just not memory-unsafe. Or why do you think things like PHP, JS, Java, etc. java security problems like crazy?

Unless and until we all admit this is entirely and exclusively a skill issue, things will not get better.

Re:

[allo]

I think they never claimed that they prevent logic bugs.

time to move on from C++ Std committee

[cleanmachine]

I fear that the C++ standards committee structure is not up to this task despite all the talent there. A major compiler project or vendor probably just needs to implement their solution and see if they can actually solve the problem.
I think it could succeed even without committee blessing because it is such an crucial need: need to avoid re-writing all our working C++ code, but we need to be able to incrementally add to it or modified part of making it progressively more safe.

If a implementation arrives th

C++ standards

[BytePusher]

Getting a proposal accepted is an incredibly high bar that requires many stakeholders to express an interest in it, including the details of the proposal. The author here clearly is just being overly sensitive and dramatic. The Rust community likes mini-dictator savants. The C++ community likes consensus and peer review.