It may be a small thing, but I really like the ability to declare variables anywhere, rather than just at the top of a block.
My next most favorite feature is member functions (i.e. the automatic passing of the "this" parameter).
-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)
While unscientific, recently I was surprised to learn that 90%+ of embedded engineers use C and C++. Having developed C and C++ compilers and embedded products, I believe both languages offer their own linguistic characteristics suitable for ASIC, CSIC, DSP, and VLIW based products.
If one uses C and wishes to take advantage "some" of the C++ features without totally converting to C++, what would be the top 5 characteristics that will enhance the embedded development in C?
Selected key C++ characteristics are:
A. Encapsulation via Abstract Data Type
B. Default constructor and destructor
C. Single inheritance
D. Visibility control via public, private, protected specifier
E. Function overloading
F. Virtual functions
G. Multiple inheritance
H. Operator overloading
I anticipate the first five (A thru E, in that order) would benefit the C development the most, because dealing with composite data via struct, functions, and static declaration is more natural to the C language, hence low overhead. Implementing overloading (function and operator) and building VTable (runtime allocation) are more expensive compared to the former group.
Has anyone done any analysis on such prioritization?
Hyoung
I don't see the point of this analysis. I use the features that have more value than cost. Why shoudl I "prioritize" these language features? Please don't tell me that you want to define a new language... Bob
Are you quite sure that wasn't C *or* C++?
I think I already have all that I want from C++ in embedded C:
A. Function prototypes
B. // style comments
-- Rich Webb Norfolk, VA
Why wouldn't you simply use a C++ compiler and choose the features that are appropriate for your application. E.g. if you don't need MI, then don't use it. Yes, this means that you have to know what you're doing :-)
-- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA 30144 "... abstractions save us time working, but they don't save us time learning." Joel Spolsky, The Law of Leaky Abstractions The Beatles were wrong: 1 & 1 & 1 is 1
embedded
building
group.
There are probably those people who get paid to sit around and analyze these things. The same people rarely can produce results quickly, efficiently and accurately on schedule and under budget; results that meet the customers demanding, ever changing needs.
Those that can be implemented without using dynamic memory (free, delete etc.).
Unless long time heap fragmentation can be avoided in a predictable way (both in size and time), I would not let the run time system do any dynamic memory manipulation under the cover.
Paul
embedded
I would add strong typing.
In general, I think you can use any feature that fits your project. Don't even think about Exception Handling in a PIC, but why not use STL in an Industrial PC-based system running WinNT embedded?
It would be really nice however to have a tool (or even the compiler) check the features I've used of a language against the set of features I've decided to allow in a particular project.
Regards, Andras Tantos
Have you thought about using the standard C++ library, but replacing the default allocator with one more suited to your application?
(like a Pool
-- Alex Pavloff - remove BLAH to email Software Engineer, Eason Technology
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.