In his C++ column over on informit.com, Daney Kaley has written a couple of articles about how C is diverging from C++. As C compilers become fully compliant with C99, the latest C standard, and (more seriously) as C standard library header files and application code evolve to adopt its features, C++ will no longer be able to compile them.
"A Tour of C99" gives a brief synopsis of the new C99 features. "Incompatibilities between C99 and C++09" points to specific areas which are likely to cause grief. He also mentions that there is (understandably) some effort at reconciling these differences. Stroustrup has called for a merging of the two languages. Unless this is resolved, those who use C++ as a "better C" are going to have some heartache. Not to mention we may have two different sets of equivalent header files to keep track of. Hopefully the implications of this are enough to bring some sanity to the situation.
One of the C99 features that caught my eye particularly was the "restrict" keyword that is used in a function prototype parameter list to offer a guarantee to the compiler that two pointers in the list cannot point to the same object. If you've done any reading on how processor memory models have evolved to break commonly used idioms like the double-checked locking pattern for implementing singletons, you can see where this is going. It sounds like an optimization enabler, something along the lines semantically of a hypothetical "guaranteed non-volatile" keyword.
Kaley was on the C++ standards committee for several years, and has a lot of interesting and sometimes scary stuff to say on this topic and other C++ issues.
Subscribe to:
Post Comments (Atom)
2 comments:
In other relevant news: will synthetic buggy whips make leather buggy whips obsolete? Will BeOS support IPV6?
Okay, it's not that bad, C/ C++ won't be displaced as the implementation language for OSes, drivers, JVMs, and all the interpreters for the juicy new languages we're using these days (Ruby, Python).
But cmon gramps, let go of those bell bottoms, start blogging about what's new in Java 6 or something.
Demian, Demian, Demian. Without C and C++, live as we know it could not exist. Besides, I've actually gotten paid to write assembly code in recent memory. And of course reference the statistics on COBOL I cited in a recent article. But I'm all for all the cool kids doing just Java and Ruby. Leave that churning molten core of legacy code to us Baby Boomers, it'll keep us employed for decades.
(Having said that, Java 6 does have this really cool feature about allocating objects on the stack instead of the heap when possible, strictly as an under-the-hood optimization. I'm excited about that -- it makes Java even more attractive as an embedded language.)
Post a Comment