Live data from Hacker News

C and C++ Aren't Future Proof

blog.regehr.org

41–50 of 108 posts

Re: C and C++ Aren't Future Proof

#41
post #6
post #2

If all people started writing code with more RAII and Smart Pointers this would be a better world. Talking about C, well... it's unsafe by nature, let's face it.

If all people started writing code in a modern C++ equivalent called Rust this would be a better world. After all in comparison Rust is safe by nature unlike C or C++. :)

It's too early yet to make claims like that. Rust may or may not end up supplanting C++ in some areas, but even in the most optimistic case it definitely won't obviate C++ entirely.

Re: C and C++ Aren't Future Proof

#42
post #33

Earlier quoted context omitted.

I'm not saying the language is some sort of security barrier that prevents any error, I'm saying sanely styled code does not have these issues in practice. The solution is "don't do that, and cultivate habits that will not cause you to do that by accident", not having the compiler make up semantics for broken code or putting in checks everywhere. Just because someone, somewhere does it wrong, doesn't mean it's imposs…

"I'm saying sanely styled code does not have these issues in practice" Otherwise known as the "just do it right" argument. This is an argument that goes all the way back to the days of writing everything in assembly language, and it was just as wrong then as it is today. If only a restricted subset of a language can ensure that basic issues do not become serious problems, then the language should be restricted to tha…

>Otherwise known as the "just do it right" argument.

Maybe, maybe not. Can you make a better example than arbitrary magic numbers used as pointers?

Re: C and C++ Aren't Future Proof

#43
post #6

Earlier quoted context omitted.

If all people started writing code in a modern C++ equivalent called Rust this would be a better world. After all in comparison Rust is safe by nature unlike C or C++. :)

Has any interesting large program been written in Rust besides the Rust compiler itself?

Not really. The closest is Servo,[1][2] the massively-concurrent browser engine that the language was designed to create. But it's not very featureful yet, and is only a few thousand lines (compared to 100+ kloc for the Rust compiler itself).

[1] https://github.com/mozilla/servo

[2] https://github.com/mozilla/servo/wiki/Design

Re: C and C++ Aren't Future Proof

#44
post #6

Earlier quoted context omitted.

If all people started writing code in a modern C++ equivalent called Rust this would be a better world. After all in comparison Rust is safe by nature unlike C or C++. :)

I've been working my way through the Rust tutorial. As much as I like the power and control it gives me, they really need to take a note from Go on the syntax. Some of the even fairly contrived examples are an eye-sore. I need to give it more time but yeesh there's a lot of syntax to look out for.

Can you give some specific examples? I myself have been known to bikeshed with the Rust devs on occasion. :P

Re: C and C++ Aren't Future Proof

#45
post #22
post #20

Wow, C and C++ have undefined behavior? I bet nobody knows that unless... they took an undergrad comp sci class. Why is this on HN? Use the right tool for the job. Sometimes that C or C++, sometimes it's not.

There is substantially more sophistication to his points than you give him credit for. If someone who is an expert in something - and he is - says something about their area of expertise that you think is obvious and simple, consider perhaps that it's your level of understanding that is lacking, not theirs.

[deleted]

Re: C and C++ Aren't Future Proof

#46
post #15

Earlier quoted context omitted.

Really? I should switch my apps from C++ to an unfinished language? I'll consider once the Mozilla foundation have written any application of note in it.

You should not switch your apps. You should stop creating new projects in C++ once Rust is mature enough for your liking. The fundamental "problem" we're having/facing with C and C++ is the investments we've put in. Lots of "infrastructure" in modern day computing relies on C and C++ and will do so for ages. We can't just drop the projects and switch to something else(say Rust or maybe Go), but we can stop creating n…

No, we can't, because Go is unacceptable (garbage collection) and Rust is no better than a figment until all of the libraries I need exist in it.

And I have better things to do than port them, because C++ doesn't bother me.

Re: C and C++ Aren't Future Proof

#47
post #40

Earlier quoted context omitted.

Much undefined behaviour can't be statically detected, unfortunately.

But the the author of the original piece is mostly concerned with undefined behavior that can be detected statically - otherwise, compilers would not be able to exploit it to make optimizations.

One thing he mentions is signed integer overflow. This is in the worst case equivalent to the halting problem, but even in practice very hard to test for at compile time.

Another behaviour he mentions is not properly return'ing at the end of a non-void function. This is again technically equivalent to the halting problem, but it is negated by the good practice of making every code path (even potentially dead ones) have a return statement (or throw an exception, etc.) Go takes this approach if I remember correctly.

Re: C and C++ Aren't Future Proof

#48
post #20

Wow, C and C++ have undefined behavior? I bet nobody knows that unless... they took an undergrad comp sci class. Why is this on HN? Use the right tool for the job. Sometimes that C or C++, sometimes it's not.

They have far too many undefined behaviors.

"Like leaving a string unfinished. You expect a compiler error right? Nope, undefined.

Any why should making an invalid pointer be undefined?

It becomes ridiculous to try to just remember the rules.

Re: C and C++ Aren't Future Proof

#49
post #33

Earlier quoted context omitted.

I'm not saying the language is some sort of security barrier that prevents any error, I'm saying sanely styled code does not have these issues in practice. The solution is "don't do that, and cultivate habits that will not cause you to do that by accident", not having the compiler make up semantics for broken code or putting in checks everywhere. Just because someone, somewhere does it wrong, doesn't mean it's imposs…

"I'm saying sanely styled code does not have these issues in practice" Otherwise known as the "just do it right" argument. This is an argument that goes all the way back to the days of writing everything in assembly language, and it was just as wrong then as it is today. If only a restricted subset of a language can ensure that basic issues do not become serious problems, then the language should be restricted to tha…

I really don't have any difficulty finding programmers who have the discipline to not use the unsafe parts of the language all over the place. C++ has an issue with having a fragmented multitude of sane subsets, but any of them are fine if they get the job done.

That said, I don't understand why you still keep putting up awful mostly-C code as if any trained C++ programmer wouldn't yell at you for doing it wrong, even before they saw the part with the error.

  for(i = 0; i 
Where did you learn this? don't do this. Everyone else knows not to do this.

  for(i = 0; i 
This is actually worse, though it does have the virtue of probably working. If you want a run-time check, use at(), or better still use an iterator already.

C++ has all sorts of issues. It's too hard to learn, it's missing some very useful features, and it has a number of rough edges that you have to learn your way around. But the things being complained about in the OP and by you are not real problems for anything but beginners. There just aren't that many naked array accesses or pointer math operations going on in an ordinary C++ application written in non-C style.

Re: C and C++ Aren't Future Proof

#50
post #15

Earlier quoted context omitted.

Really? I should switch my apps from C++ to an unfinished language? I'll consider once the Mozilla foundation have written any application of note in it.

You should not switch your apps. You should stop creating new projects in C++ once Rust is mature enough for your liking. The fundamental "problem" we're having/facing with C and C++ is the investments we've put in. Lots of "infrastructure" in modern day computing relies on C and C++ and will do so for ages. We can't just drop the projects and switch to something else(say Rust or maybe Go), but we can stop creating n…

Exactly, it's a chicken and egg problem. C++ has tons of libraries, while Rust has barely any. Rust can use external C bindings, but not C++ ones yet. I think if they solve the issue of using C++ libraries from within Rust, the transition will be much easier, and meanwhile more native Rust libraries will be created.
Post reply on HN