C and C++ Aren't Future Proof
blog.regehr.org
C and C++ Aren't Future Proof
1–10 of 108 posts
Re: C and C++ Aren't Future Proof
#2If 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.
Re: C and C++ Aren't Future Proof
#3If 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.
Worse is better, right?
Re: C and C++ Aren't Future Proof
#4So far I doubt C++ is going anywhere - it's here to stay. When the usage of such languages as Rust will gain more traction up to the point that high performance games engines will be written in it, one could start saying that C++ is being pushed out. But it's really somewhere in the future.
Re: C and C++ Aren't Future Proof
#5> This propensity for today’s working programs to be broken tomorrow is what I mean when I say these languages are not future proof.
It doesn't matter. This is not how programming works in the real world. In the real world, you write the most correct program you can under time pressure. A new compiler, operating system, or platform arrives that exposes a bug. You fix it and you move on. It doesn't matter if the language is future proof or not. The process is similar for any complex program.
The blog's name is "Embedded in Academia" and this is perfectly valid viewpoint for someone in academia to take. And people in academia should research towards building more robust tools and languages. But it really is not going to matter in the real world. Languages and platforms will always not be future proof because computing is complex.
Re: C and C++ Aren't Future Proof
#6If 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++. :)
Re: C and C++ Aren't Future Proof
#7Sufficiently Smart Compilers vs. Sufficiently Dumb Code
Re: C and C++ Aren't Future Proof
#8A side note I took away from this post is the existence of Frama-C, which appears to be a quite nice, open-source analyzer: http://frama-c.com/
Re: C and C++ Aren't Future Proof
#9> This propensity for today’s working programs to be broken tomorrow is what I mean when I say these languages are not future proof. It doesn't matter. This is not how programming works in the real world. In the real world, you write the most correct program you can under time pressure. A new compiler, operating system, or platform arrives that exposes a bug. You fix it and you move on. It doesn't matter if the langu…
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 people finally did about unsanitized format strings, or the use of unbounded sprintf().
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.
Re: C and C++ Aren't Future Proof
#10This caught my eye "Program analyzers that warn about these problems are likely to lose users."
For me, this is perhaps the biggest issue raised in this article, as static and dynamic analysis tools become more ubiquitous we should be learning to fix the issues that they raise, not ignore them.
I remember a while ago (2004 or 5) interviewing a college-hire candidate, I had asked about working with others and we had gotten to talking about code review - the candidate was passionate about how code review had helped with a group project he worked on, but every single example he gave of a a bug found by code review was something that -Wall would have found...
The same applies to static analysis - let the machines do the work that they can do, that leaves the humans to get on with the work that the machines can't do (yet!)