I really wish we would disconnect C and C++. They're different langauges used entirely differently by different people, and C++ gives C a bad rep.
I cannot consistently write safe C/C++ code
101–110 of 123 posts
Re: I cannot consistently write safe C/C++ code
#102Isn't this the same as saying you can't consistently write bug-free code?
And isn't this sort of the holy grail of CS?
Re: I cannot consistently write safe C/C++ code
#103Safety, speed, language convenience.
Pick 2.
Safety is an issue everywhere you are programming something, good programmers just know how to mitigate it.
And to be really honest, you don't always need to use C++. Just use it where performance is needed, write good code, review it, etc, and when you need to go at a higher level, use python or any other scripting languages. C++ should be used to write libraries.
There are not so many softwares in the world that need to be entirely written in C++, and if they do, more time is spent writing and fixing such software.
"There are languages people complain about, and languages nobody use".
I don't dislike rust, but when I read its syntax, it doesn't seem simple enough to learn, read and write, the learning curve seems pretty steep, so it won't really do well with students.
Re: I cannot consistently write safe C/C++ code
#104Earlier quoted context omitted.
The big safety wins from Rust for me are things like the type system disallowing iterator invalidation, the type system handling resource releases, iterators making bounds checks a lot more affordable, the shared immutable/unique mutable distinction, the ability to encode that something can't keep a value somewhere accidentally, type system enforced thread safety, and others in that category. Why would I need a good…
I don't think you need a good understanding of C++ to appreciate these features per-se. Only if you want to make a statement like "X is an improvement over C++ because of these". For example, enforced const-ness/immutability, option types and automatic ressource management (RAII) are also already standard in modern/best-practice C++ code. In general I agree that there are a lot of nice languages features that rust cu…
> I don't think you need a good understanding of C++ to appreciate these features per-se. Only if you want to make a statement like "X is an improvement over C++ because of these".
What about "X encoding thread-safety through the type-system is an improvement over the C++ way" and similar? This is how I usually read these kinds of statements.
Re: I cannot consistently write safe C/C++ code
#105Earlier quoted context omitted.
Fact 1, the article doesn't mention Rust a single time. Fact 2, mostly safe systems programming languages exist since ESPOL (1961), 10 years older than C, and with a great linage of attempts of safe systems programming outside AT&T walls, so plenty of alternatives are available So as someone with more than 10 years of C and C++ experience, among other programming languages, before focusing on Java and .NET, I find th…
I feel you're missing my point. The article doesn't mention rust but my comment was phrased in the context of the current rust craze on HN. As I said, I agree with you and the author that all of us do inevitably make mistakes. I also agree that the c-family of languages makes it somewhat more easy to shoot yourself in the foot in a bad way than others. I'm not saying innovation on safe languages is bad, or that using…
There's a broader question of when to investigate a technology yourself versus learning from others. A new programmer could spend ten years programming in [some language] or they could learn from other people to avoid it, and possibly save themselves a lot of time. Yes, that means you're just following the bandwagon, but sometimes that's efficient.
I would share the link, though, rather than making my own assertions, and be open to other arguments from more experienced people.
Re: I cannot consistently write safe C/C++ code
#106Earlier quoted context omitted.
Fact 1, the article doesn't mention Rust a single time. Fact 2, mostly safe systems programming languages exist since ESPOL (1961), 10 years older than C, and with a great linage of attempts of safe systems programming outside AT&T walls, so plenty of alternatives are available So as someone with more than 10 years of C and C++ experience, among other programming languages, before focusing on Java and .NET, I find th…
I feel you're missing my point. The article doesn't mention rust but my comment was phrased in the context of the current rust craze on HN. As I said, I agree with you and the author that all of us do inevitably make mistakes. I also agree that the c-family of languages makes it somewhat more easy to shoot yourself in the foot in a bad way than others. I'm not saying innovation on safe languages is bad, or that using…
[deleted]
Re: I cannot consistently write safe C/C++ code
#107Earlier quoted context omitted.
I'm talking safe as in Rust's memory safety guarantees.
As far as I understand, there is no accepted formal specification or even single source of truth for what the rust community thinks are the "rust memory safety guarantees". Only a large number of people that have completely convinced each other that "it's better than C++" with little proof and without even clearly defining their own semantics. Please correct me if I'm wrong here (a blog post does not qualify as a spe…
It's a little more subtle than that: It's "safe code must be memory safe" and "unsafe code infects the whole module". The stuff you're talking about is "what exact invariants are unsafe code supposed to uphold". Because unsafe Rust is a superset of safe Rust, that being an open question does not mean that what's meant by "Safe Rust" inside of safe Rust is up for questioning.
Work on exactly what unsafe code is expected to do is ongoing.
Re: I cannot consistently write safe C/C++ code
#108Earlier quoted context omitted.
Let's say you're a fresh grad and looking at options for you future dev career: Option 1. Spend the next 5 years learning the ins and outs of C++, where it can bite you, where it can go wrong, all the intricate edge cases, etc... and you'll come out a better C++ programmer. Hopefully after 5 years of hard concentration, you may be able to write safe code (I still haven't met a C++ programmer that hasn't been burned b…
That assumes there will be no errors in the Rust compiler or runtime environment to deal with. If there are then those would definitely be above their pay grade.
Rust has basically the same amount of runtime as C; I'd say "standard libraries" here instead, personally.
Re: I cannot consistently write safe C/C++ code
#109Earlier quoted context omitted.
> or a surgeon refusing to wash their hands because they're careful never to touch anything contaminated. Fun fact, although perhaps this is specifically what you had in mind: This was pretty much the case until Ignaz Semmelweis [1] noticed that washing your hands caused patients to die less frequently. His suggestion was not well-received by the establishment: > "Some doctors, for instance, were offended at the sugg…
I don't think it's inaccurate at all. Software development needs a scientific revolution equivalent to that of medicine, wherein every pattern and practice has to be backed up by evidence from a randomised, controlled trial. I remember sitting in a "software quality" workshop organised by a coder at an old employer. He was enumerating various patterns and best practices, and yet I realised that nothing he was saying…
> I'd apologize for going off on a tangent if it wasn't such an accurate analogy.
> I don't think it's inaccurate at all.
an accurate - not inaccurate! :)
Re: I cannot consistently write safe C/C++ code
#110Earlier quoted context omitted.
I'm talking safe as in Rust's memory safety guarantees.
As far as I understand, there is no accepted formal specification or even single source of truth for what the rust community thinks are the "rust memory safety guarantees". Only a large number of people that have completely convinced each other that "it's better than C++" with little proof and without even clearly defining their own semantics. Please correct me if I'm wrong here (a blog post does not qualify as a spe…
It's nowhere near that uncertain. "Memory safety" is hardly a subtle property and it's been well-understood since we figured out how to enforce it in garbage collected languages.
The only uncertain part is which rules unsafe code has to follow to maintain it- it currently comes down to "whatever LLVM optimizations won't break," which is in practice what C and C++ programmers deal with already. Things like your link are work to improve the situation beyond C and C++.