Live data from Hacker News

C and C++ Aren't Future Proof

blog.regehr.org

21–30 of 108 posts

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

#21
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…

My new projects rely on C++ libs, so I can't use Rust.

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

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

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

#23
post #17
post #12

Earlier quoted context omitted.

> His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves. I've written Windows, Mac, Linux, Xbox, PlayStation, PSP, iOS, and Android code. The memory model is subtly different for each platform. I just don't think you can define certain behaviour and have that work across disparate pl…

Ostensibly, a platform like Java or Rust is supposed to abstract stuff like the memory model. I haven't written a lot of Java code, especially not Java code that runs on many different native system / VMs, but from my perspective of blissful ignorance, it seems to have done the job? Same with other high-level VM based languages like Python...

For most programs, yes they have done their job. However, in certaint categories of applications (for example, server software) it's somewhat of a leaky abstraction. Garbage collector sweeps, circular references, etc are all pains which force you to be aware of how the vm is managing your memory.

For an impression, see this excellent blog series on how a certain garbage collector sweep issue was solved: http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-h...

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

#24
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++. :)

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.

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

#25
post #12
post #9

Earlier quoted context omitted.

The particular kind of not-future-proofness he has in mind seems pretty practically important: code that relies on this undefined behavior often suffers from exploitable security holes. Just because computing is complex doesn't mean you have a free pass if you shoot yourself (or your customers) in the foot the same way the previous 100 folks did. If it happens enough, it becomes prudent to do something about it, like…

> His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves. I've written Windows, Mac, Linux, Xbox, PlayStation, PSP, iOS, and Android code. The memory model is subtly different for each platform. I just don't think you can define certain behaviour and have that work across disparate pl…

You certainly could define some basic things to make the language safer. For example, make variables always be initialized to zero if not explicitly initialized, and force accessing beyond the bounds of an array to be a fault rather than undefined behavior.

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

#26
Hey, don't lump C++ in with this. If you write code in the STL weenie style or the Pretend It's Java style there aren't any idioms I know of that would ever violate the rules he mentions (out-of-range pointers, signed overflow, invalid aliasing). I don't do those things and the C++ programmers I work with don't do those things, at least not habitually. I don't see violations of undefined behavior rules, or the use of idioms that come close to it, very often in our code. Not nearly as often as the sort of mundane errors that no language can prevent.

These are not problems of a language per se, but the original sins of neo-vaxocentrism and confusing "I understand how this might work, at some random abstraction layer" and "I can depend on what happens when I do something stupid". Free your mind of these and the rest will follow.

These low-level bit banging errors are vastly less common than shared-memory concurrency issues, which as far as I can tell are endemic to all code that attempts shared-memory concurrency, in any language. If you want to have an axe to grind about languages that aren't future proof, look there.

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

#27
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 people treated C++ as a maintenance-only language and used it only for legacy code -- like COBOL -- the world would be a better place. The world would also save billions of dollars.

This is not a matter of RAII or "smart" pointers (which are not even smart enough to deal with cyclic references unless the programmer explicitly breaks the cycle). It is a matter of a language whose high-level features are constrained by low-level concerns, where the features compose poorly, and where things that are obvious (like requiring that functions with a non-void return type have a return value along every control path) are simply omitted from the standard. It is dizzying to think of how much money has been spent on bugs that were made possible by C or C++; why are we continuing to waste time and money on these languages?

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

#28
post #17
post #12

Earlier quoted context omitted.

> His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves. I've written Windows, Mac, Linux, Xbox, PlayStation, PSP, iOS, and Android code. The memory model is subtly different for each platform. I just don't think you can define certain behaviour and have that work across disparate pl…

Ostensibly, a platform like Java or Rust is supposed to abstract stuff like the memory model. I haven't written a lot of Java code, especially not Java code that runs on many different native system / VMs, but from my perspective of blissful ignorance, it seems to have done the job? Same with other high-level VM based languages like Python...

It works, but to get C to expose the same memory model on different platforms you would have to compromise the performance and close-to-the-hardware nature that are the only reason to use C nowadays.

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

#29
post #26

Hey, don't lump C++ in with this. If you write code in the STL weenie style or the Pretend It's Java style there aren't any idioms I know of that would ever violate the rules he mentions (out-of-range pointers, signed overflow, invalid aliasing). I don't do those things and the C++ programmers I work with don't do those things, at least not habitually. I don't see violations of undefined behavior rules, or the use of…

"If you write code in the STL weenie style or the Pretend It's Java style there aren't any idioms I know of that would ever violate the rules he mentions (out-of-range pointers, signed overflow, invalid aliasing)."

What does the STL do about signed overflow? As for out of range pointers, that is an easy one to get with the STL:

  vector somevector(100);
  somevector[200] = 5;
"These are not problems of a language per se"

Yes they are: the default numeric type is fixed-width, pointers pop up all over the place and pointer dereferences are unchecked by default. Personally, though, I would have chosen (as the article's author did) the more severe deficiencies in the standard, like the lack of any requirement that a function with a non-void return type have a return statement along every control path or the fact that there is no reliable way to signal errors that occur in destructors.

"These low-level bit banging errors are vastly less common"

Not in my experience, and not judging by the number of bug reports and vulnerabilities I have seen that stem from low-level mechanics.

Post reply on HN