>> We ditch the C and C++, and port our systems code to Objective Ruby or Haskell++ or whatever. omfg:))
Objective Ruby ? What's that?
This is suggestion from articke to code in and I have no idea wtf it is
C and C++ Aren't Future Proof
101–108 of 108 posts
Re: C and C++ Aren't Future Proof
#102Earlier quoted context omitted.
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) ha…
It can't always be tested for at compiler time but the problem he's complaining about is when C compilers do detect signed integer overflow. What happens is that someone writes code that in practice handles signed integer overflow fine, then a while later the C compiler developers get clever, detect the integer overflow, and decide to optimize that code away because it's invoking undefined behaviour and they can do w…
The common case is (probably) not that a compiler detects an instance of signed over/underflow. Instead, it can assume that this never happens and generate "dangerous" code.
A good post describing how these optimizations come about is http://www.airs.com/blog/archives/120
More options to warn about uses of or disable these optimizations would be welcome in compilers.
Re: C and C++ Aren't Future Proof
#103Earlier quoted context omitted.
Much undefined behaviour can't be statically detected, unfortunately.
Is there a way to detect it dynamically, e.g. by running C code under a debug mode or in an interpreter that errors out when undefined behavior is encountered? I've occasionally wanted to have something like that to use in tests, so I could ensure that at least my common code paths aren't relying on undefined behavior. I know about gcc's -ftrapv and a few other options, but nothing comprehensive.
Besides the already mentioned:
- IOC : low overhead, only for integer overflows
- KCC : high overhead, for all kinds of undefined behavior, limited standard library support (and source-level only)
- Valgrind : medium overhead, for various memory errors, binary, may fail to detect undefined behaviors that have been made undetectable by compilation.
You may also find:
- various memory-safe C compilers. There are plenty here, I had better let you do the googling. medium overhead, generally better than Valgrind at being sound (since they work at source level), unless they trade efficiency for soundness: http://research.microsoft.com/pubs/101450/baggy-usenix2009.p... . May require all source code to be available.
- Frama-C's value analysis, a static analyzer that can be used as a C interpreter. This is what I work on. Limitations comparable to KCC, quite a bit faster (but still high overhead), some slightly different design choices. I do not have a good single write-up for this use, but some details are available at these URLs:
http://blog.frama-c.com/public/csmith.pdf
http://blog.frama-c.com/index.php?post/2011/08/29/CompCert-g...
Re: C and C++ Aren't Future Proof
#104Earlier quoted context omitted.
If those things are bad, why does the standard allow them? If any trained C++ programmer would know not to write that sort of code, what purpose does allowing it serve ?
Because sometimes for loops are useful. It's no use trying to list up all use cases of for that are safe and/or useful, and prohibit those that aren't. There is a trade off between designing all sorts of safety checks into a language and raw power, and C++ mostly errs on the side of raw power. Which is largely why it's so prevalent and dominant. I own a pneumatic nail gun that has two rather rudimentary safety featur…
"There is a trade off between designing all sorts of safety checks into a language and raw power"
This is a false dichotomy. Safety checks can be disabled if they become a performance problem in languages like Lisp. Safety checks can often be removed by a good compiler when the compiler can infer that the check will always be satisfied.
C++, however, provides nothing by default -- as opposed to being safe by default, and allowing programmers to be unsafe if they explicitly request that.
Re: C and C++ Aren't Future Proof
#105Earlier quoted context omitted.
How many Rust libraries are there for various tasks? What IDE supports Rust? What tutorials, books and conferences exist that teach and distribute the state of the art in development techniques? What example projects have been build in it to demonstrate its feasibility for large projects? What tools support Rust (continuous integration, code formatting/checking, build tools, ...)?
I'm sure make and git work with Rust like anything else.
Well using make as an example of anything good is... let's say 'suspicious'. There is more to tooling than make and git (note that I deliberately omitted version control from my list)
Re: C and C++ Aren't Future Proof
#106Earlier quoted context omitted.
You're ignoring the cost of actually running the applications in question. The benefits of reduced development costs can quickly be negated if performance starts to suffer. We see this a lot with Ruby on Rails web apps, for instance. Perhaps they're quicker to develop in many cases, and maybe they're slightly less vulnerable to certain problems than C or C++ apps are, but they are much less efficient at runtime. This…
Why are you ignoring HotSpot?
Because it has pretty significant memory overhead, and because its runtime performance usually isn't better than compiled C or C++ code.
Re: C and C++ Aren't Future Proof
#107Earlier quoted context omitted.
Why are you ignoring HotSpot?
Because it has pretty significant memory overhead, and because its runtime performance usually isn't better than compiled C or C++ code.
Yeah but in high performance web app the real competence for C and C++ are JVM languages (Java, Scala, etc.), not Ruby and Python. Twitter switched from Ruby to Scala/Java because Ruby performance was terrible.
Could they have used C/C++ for better performance? Yeah, but Java was goodEnough and for most high performance web apps it is GoodEnough, the cost being some more money for hardware (for Ruby and Python the cost is a lot higher and sometimes not even with expensive hardware you can solve the problems):
http://c2.com/cgi/wiki?GoodEnough
Just like C++ became GoodEnough and people switched to it from C for high performance apps, just like C became GoodEnough and we switched from assembly to C.
Re: C and C++ Aren't Future Proof
#108Wow, 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.
Academics have been whining about C and C++ since at least the 1980s. But if you ask any three academics what programming languages they like, you'll get three different answers, depending on what department and program they are in.
I'm sure Dr. Regehr is a smart guy, but I don't consider academics good sources of advice on software engineering, for the same reason I don't get sex tips from Catholic priests. Also, John Regehr's CV relates more to static analysis than software engineering anyway.