Politicians who know nothing about those subjects should have no say.

Some ethical guidelines are very important though. We usually don’t want to conduct potentially deadly experiments on humans for example.

Reminds me of the Epicurean Paradox:

The article mentions how basic programs are missing. They acknowledge the existence of FOSS alternatives, e.g. GIMP instead of Photoshop Elements, but complain about it being too difficult or that some alternatives are simply not to be found via Mint’s “Software Manager”.

Which is not news and probably one of the reasons why desktop Linux-based distros have still not become mainstream. There’s just a lack of all that “user-friendlyness” less tech-oriented people need.

These things can be changed, although there is an economic barrier. FOSS projects are great and we see how many of them took off. However, if the main portion of users are not on Linux, but on Windoofs, then it doesn’t make much sense to invest time and money into developing and maintaining software for Linux while having commercial interests.
The sad reality is that Microsoft has gained that market dominance. You won’t get end-user oriented software companies on board with Linux as long as the user-share is so comparably low. This is a self-reinforcing cycle.

Windoofs meets UX needs and there is a lot of software people need -> most people use Windoofs -> companies develop and distribute for Windoofs -> people keep using Windoofs, etc…

To break out of that, people need convincing alternatives. Not just for Linux alone, but especially for the software running on it.

Which is hard to achieve, given how a plethora of Linux projects have to survive on donations alone and too few companies take the leap.

There is a silver lining though. With the Steam Deck and Proton, Valve really got a lot more people on board with Linux. I can only hope, that this trend continues.

But at the moment I fear that this will be short lived, especially with Microsofts “handheld Xbox” on the horizon.

So let’s see, how this unfolds. The EOL of Windows 10 is really a strong incentive to switch to Linux. For my part, I will go for the full switch, since I’ve used Windoofs mainly for gaming anyway and am using Linux systems daily for my job. But then again, I am an engineering scientist and I can’t picture, e.g., my parents being satisfied with a Linux distro.

The definition of “a memory safe programming language” is not in debate at all in the programming community.

Yes, my mistake. I’m sorry.

This is incredibly arrogant, and, tbh, ignorant.

You’ve willingly ignored the remaining part of that context, where I explicitly admitted problems in common usage. It was not my intention to come across as arrogant.

there is no language construct in place to protect from these trivial memory safety issues

Depending on what you mean by “language constructs”: there are, e.g. RAII or smart pointers. But they aren’t enforced. So it’s correct to say that C++ is inherently memory unsafe due to the lack of such enforcements. The discussions here changed my opinion about that.

Yupp. I’ve changed my stance on this.

Since C++ doesn’t enforce memory safe programming paradigms, it is inherently memory unsafe.

You’ve missed the context. There are occasions in Rust where you have to use more boilerplate code which you wouldn’t have to implement in C++ to that extent.

But saying that C++ is free of boilerplate is of course ridiculous, if you are not able to heavily leverage templates, CRTPs, macros and alike.

Yes. I stopped now. I was hinted towards the usual definition of memory safe languages at another point in this discussion.

Although it is perfectly possible to write memory safe code in C++, I agree that the lack of enforcement makes it inherently unsafe.

No. I changed my mind just very recently throughout this discussion.

I agree now that the lack of enforcement of memory safe techniques in C++ makes it inherently memory-unsafe.

That doesn’t change the fact though that it’s possible to write memory safe code, if you know what you’re doing, use the right patterns, classes etc…

I’m not. But in my experience, using memory safe programming patterns, classes and possibly additional testing and analasys tools do the job quite well.

But yeah. I changed my mind about this memory-safety-property. The lack of enforcement really does make C++ inherently memory unsafe.

You’re right. Thanks for the links. Although I still think that C++ provides the tools to enable memory-safe programming, I guess the lack of enforcement makes it inherently memory-unsafe.

Point taken, I’ll stop saying that.

does not warn anywhere

This is incorrect. If you properly test your code such errors will become visible. It’s not too much of an ask to conduct systematic software testing. You should do it anyway regardless of the language used.

you are really thinking that you are the perfect coder who jever makes any mistakes. It does not make sense to argue with you

You are quick with being judgemental and ignoring the rest of what I said in that part, which is why I agree with you. This discussion is no longer productive.

I hope they feel welcomed here to stick around. I’ve quit Reddirt in 2023 during the API exodus, came to Lemmy and never looked back.

This is such a weird take. C++ isn’t memory safe. The blanket statement is… true. You say as much in the second sentence.

I suppose we need to make definitions clearer. C++ is memory safe in the sense that you can write memory safe code. It doesn’t enforce memory safety though. But not doing that is not the language’s fault. If someone jumps with a bike from a flying airplane, it’s not the bike’s fault that they will not land safely. It’s the misuse of the bike.

The best developers money can buy still make mistakes with C and C++.

I’d argue those weren’t the best developers then. However, I don’t want to get ridiculous. I see that there are problems in the common use of C++. Although I can’t share that from my experience due to usually proper usage, thorough testing use of additional tools, there is surely a need for aiding C++ devs with writing safe code. I know of the corresponding security concerns as well as probably everyone else in the C++ community.

There are proposals to improve on that. Some of those might already come with C++26. Stroustrup’s favourite are Profiles to provide and enforce further guarantees, while others propsed an extension like Safe C++. Whereever the future will take us with C++, I’m confident that this issue will be sufficiently solved one day.

There was a time when C++ wasn’t even designed for multi-processor systems, lol. That was redesigned pretty late. Much has changed and it will continue to improve as C++ continues to mature.

Edit: Just saw your convention examples after I’ve sent my reply. Idk why it wasn’t displayed before.

Regarding the double free: It’s clear from the documentation that this returns a raw pointer.

Regarding the use after free:
I really don’t want to sound arrogant as this is a simple example of course, but that is such an obvious mistake and looks like a topic which is covered in C++ beginner classes. To me, this is almost on the same level as dividing by zero and wondering about resulting bugs.

but the developer needs to know all of them to not make the mistake

Yes. Not every language is as user-friendly as python. With more flexibility come more risks but also more rewards if you’ve mastered it. It depends on what you want to do and how much you’re willing to invest. I would at least expect a professional dev to rtfm. Which itself is apparently already a problem. But, in the end of the day we want to use tools, which are effective and easy to use. So sure, point taken. I refer to the section before my edit regarding developments upon improving such aspects in C++.

I’ve a very long track record using C++ as well and I can’t share the feeling. I don’t say it’s alyways easy. I’m just saying that it’s doable and therefore whether the software is memory safe depends on the expertise of the devs. Modern C++ practises, programming patterns and as well tools from the STL (or even your own implementation) make life a lot easier. If you don’t use them, that’s not the languages fault. In the end, how you use the language still matters a lot. If you’d like to think less about memory management, go on and use Rust or C# or Java or even Python if performance doesn’t matter. That’s perfectly fine. This can come with other issues, like more boilerplate in the case of Rust for example, but in the end those languages are tools. Choose the tool which gets your job done.

I think it boils down, how we define “memory safe”. C++ is perfectly memory safe, if you know what you’re doing. A lot of people don’t. Which is why Rust was born. that doesn’t make C++ a memory-unsafe language. It just demands more responsibility from the user. A design philosophy that comes with a lot more flexibility than Rust can offer.

Which is fine. Both languages have their perks. But saying C++ isn’t memory safe, while Rust is, is in my opinion just plainly wrong. Besides, with “unsafe” Rust inherently already the door for memory issues.

Modern C++ practises and dev patterns can handle most memory issues in C++ pretty easily. Consider smart pointers for example, or RAII.

It’s not the language’s fault if it is used wrong.

That was not the only aspect, but yes, I mentioned that.

I don’t dislike Rust. I find it pretty cool. However, I disagree with the blanket statement “C++ isn’t memory safe”. C++ provides the tools for writing memory-safe code, but it does not enforce it by default. That’s a design choice: favoring flexibility over strict enforcement.

Yes, you can make mistakes that lead to memory issues. But that’s not a problem with the language itself; it with how it’s used. Stupid example: if you write code, which divides by zero at some point and you don’t make sure to check that, this is not the language’s fault, but your own.

Of course a language can accomodate for stuff like that and lift some of that burden from the user. Surely there are plenty of use cases and user groups for that. And that’s totally okay. Rust was designed with memory safety in mind to prevent common errors that occur to a lot of devs during the usage of C++, which is fair. But that doesn’t make C++ less memory safe. It is intentionally open and flexible on purpose. There are various programming patterns and even functionality within the STL that help to prevent memory issues.

So in other words: C++ is a tool, just like Rust. If you don’t know how to use the tool, that’s not the tool’s fault.

C++ makes that a bit better with the smart pointers at least, but those have some rules that aren’t enforced by the compiler but instead by convention.

You can always implement your own smart pointers. Besides that: which conventions do you mean?

Basically I find the phrase “fighting the borrow checker” to be shorthand for “I can’t write C or C++ in Rust and I want to”.

Nah, although it has its persk, I just think that it also imposes a rigid framework that sometimes forces you into cumbersome workarounds. With C++, you retain full control over memory management and can choose the best tool for the job. You’re not boxed into a strict ownership model that may force refactoring or add extra layers of abstraction. Instead, you have a mature ecosystem with decades of evolution that lets you balance safety and control based on context. Sure, mistakes can happen, but with proper practices and modern C++ features you can achieve a level of safety that meets most needs without sacrificing the expressiveness and efficiency you might require in complex systems.

It’s not just about runtime performance, but also about coding flexibility, and for example also reduction of boilerplate.

I’m not just talking about performance costs. For example, compared to C++, Rust comes with reduced flexibility and increased complexity in certain cases.

The borrow checker, for example, imposes strict ownership and lifetime rules, which can be difficult to work with, especially in complex data structures or when interfacing with existing systems. Sometimes, you have to significantly refactor your code just to satisfy these constraints, even when you know the code would be safe in practice. This can slow down development, require more boilerplate, and make certain patterns harder to express.

C++ gives developers more freedom but expects them to take responsibility. That tradeoff isn’t just about raw performance; it’s also about how much control and convenience the developer has.

If a language prevents you from doing stuff like that, this always comes at a cost, since it has to do the work for you, almost always. This is additional overhead you can get rid of in C++ and therefore gain a lot of performance. But that again comes with more responsibility on the developer’s side and you might need to implement appropriate checks yourself where needed.

I don’t like that “C++ isn’t memory safe”. It is. Users of that language are usually just not experienced or educated enough and therefore more mistakes happen.

I agree though, that other languages like Rust or Java can make it easier to prevent such mistakes.

In my experience, using smart pointers alone already solves 90% of memory issues I have to deal with. C++ improved a lot in that regard over the decades.