The Embedded Newsletter is delivered to you free of charge from the staff of Embedded.com. To view the Embedded.com site , visit: http://newsletter.embedded.com/cgi-bin4/DM/y/ hBTmz0HSUaV0FrY0NYs0EA
It seems very interesting.
I of course believe C and C++ will still be going strong in 50 years. I just love debugging machine generated code. NOT!
TECH FOCUS - WHITHER C/C++ IN THE AGE OF MULTIPROCESSING?
08-31-2009
After several weeks of debate over Michael Barr's recent column (Real Men Program in C) at the Embedded Forum, Dan Zak's reasoned response in "Poor reasons for rejecting C++" is a breath of fresh air. Although he is passionate in his columns on the applicability of C++ instead of C even for low level code, his main point in his most recent column is that it is necessary to use the tools appropriate to the problem.
But what is the right tool in more complex designs? Even major players such as Intel are uncertain. On the one hand Intel has been a major promoter of OpenMP, a parallel programming API extension to C. But Intel has also been much interested in Ct, an extension to C++ for parallel programming. And now Intel has acquired RapidMind, a software vendor with a commercial version of the Ct programming framework.
Which way to go, especially in embedded systems? To help you make up your mind we offer several articles on RapidMind's frame work including: "C++ Meets Multicore" and "High level programming model simplifies multicore design." We've also got articles on single chip coherent multiprocessing, multicore software design issues, customizing algorithms to utilize multicore hardware and the use of virtualization and visualization in multicore software development.
If Dan's reasoned defense of C++ is convincing, you might also want to read some of the other recent design articles on topics such as: C++ for the cautious embedded programmer, a survivor's guide to C++, MISRA C++ as an alternative to C and guidelines to using C++ instead of C in your embedded design. Good reading!
(Embedded.com Editor Bernard Cole, bccole@acm.org)
No comments:
Post a Comment