Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment Re: Keep rust in rust (Score 2) 86

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 make the language memory safe at all, but that catches enough bugs to be close enough (they hope).

We'll see whether that is implementable, practical and enough to satisfy regulators.

Comment Re: Huh? (Score 2) 86

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 library.

Comment Re:C++ interop is hard (Score 1) 17

The biggest problem are the platform ABIs that are not expressive enough for either rust or C++. That means both sides do tricks to smuggle extra information through the C-compatible platform ABIs -- or to pass constructs entirely around that ABI. E.g. name mangling is used to smuggle function overloading through the C ABI by encoding type information into the symbol name which is just a string.

Things going around the ABI is all the stuff that C++ requires to always be in a header file. Those headers get directly included into the user of a library, going around the ABI layer completely.

The challenge for interoperability is to extract all the necessary information from one language and make that available in the other. Gathering that information without some defined ABI means extracting it from the source code of the language itself. That is damn hard, especially if one side is C++ that needs heuristics to even get parsed.

Meanwhile Rust-inspired safety principles and constructs are being added to C++ right now in the form of Circle C++ and an enhanced libstdc++, and in the near future in the C++ standard. The future for C++ is quite bright and will allow more cost-effective ways of retrofitting safety onto existing C++ code.

There is a proposal to have Rust semantics in C++. Nothing more. It will take decades to get that through the committee, with prominent members already having said that all other venues need to be explored before this proposal can be considered.

Sean having suggested to not have a new C++ standard library (but to use rusts instead) is not going to help find support inside the committee.

Comment Re: Bugs prevented per line of C++ code (Score 4, Insightful) 140

You should write correct code everywhere.

Yeap, but humans just can not do that. We need tools to help us.

C++ isn't Rust. Are you now suggesting that C++ adopt implementation details of Rust to solve a problem?

... and yet that is exactly what the "Safe C++" proposal is that has hit the committee recently.

Comment Re:Good and bad (Score 4, Insightful) 140

"The responsibility is on our ecosystem, not the developer"

This is false. You need to train your developers (unless they're already skilled).

We are pretty much the only industry that thinks like that. There is no contradiction between "improve eco system" and "train developers". All the other industries around us do both.

We are also pretty unique as an industry in that we watch our products fail and then go "there is nothing we can do about that, sucks that random people were too stupid to write proper code". We urgently need to improve, or we need regulators to step in to make us improve. Code is just getting too important to continue with our attitude.

Comment Re: Yeah, but that's the justification... (Score 1) 258

There was an interesting paper recently that looked at first time contributors to open source projects. They found that their first few patches are way more likely to introduce vulnerabilities when the code base is in C++ compared to Rust. The difference gets smaller the longer the contributor is around but never vanishes.

Maybe the devs are not bad, maybe it's you setting them up for failure?

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fcypherpunks.ca%2F~iang%2Fp...

Quote from the conclusion ofnthenpaper:

> Namely, while it may still be true that Rust may feel like a more difficult language to learn, in at least some ways, new contributors actually benefit from its adoption, with their first contributions being less than 2% as likely to introduce vulnerabilities as C++,

Comment Re: Possible vs. Enforced (Score 1) 258

> If the compiler barks you should be really careful about that unsafe block over there because memory but hey this block over here which results in melted steel when not done in the correct sequence is not marked for safety by the language and therefore does not deserve attention according to the language, what is the implication from a psychology perspective?

It absolutely would bark at "this melts metal when done wrong". Any sane rust dev would make that a unsafe function, so you would need to call that in an unsafe block.

Submission + - Opus 1.5 is Out: The Opus Codec Gets a Serious Machine Learning Upgrade

jmv writes: After more than two years of work, Opus 1.5 is out. It brings many new features that can improve quality and the general audio experience through machine learning, while maintaining fully-compatibility with previous releases. See this release page demonstrating all the new features including:
  • Significant improvement to packet loss robustness using Deep Redundancy (DRED)
  • Improved packet loss concealment through Deep PLC
  • Low-bitrate speech quality enhancement down to 6 kb/s wideband
  • Improved x86 (AVX2) and Arm (Neon) optimizations
  • Support for 4th and 5th order ambisonics

Comment Re:Deadlocks in Rust are solved how? (Score 1) 44

Rust does not make deadlocks safe (they cannot be). Rather, it disallows some ways of structuring your code and will then refuse to compile your code until you've written it in a way that the compiler can prove that a deadlock (or memory error, or other types of error) cannot occur. That can sometimes make Rust code much harder to write, but the benefit is that you can be much more aggressive at using threads because you don't have to "play it safe because of the risk of errors".

Slashdot Top Deals

"Would I turn on the gas if my pal Mugsy were in there?" "You might, rabbit, you might!" -- Looney Tunes, Bugs and Thugs (1954, Friz Freleng)

Working...