We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I'm an Italian engeneer and in my factory, we use the C166 compiler on our boards equipped with the C167Cr microcontroller. I'm interested to receive information about a C++ compiler because I'd like to introduce the object oriented programming model in our office. If there is somebody who can tell me more about this, please do it. Thanks, Ing. Ciro Nappo
C++ can have quite a bit of overhead in code and memory to support objects, therefore C++ is normally not used on the smaller processors. Processors like the 80c51 and 80c166/7 are normally used in systems where response time is critical and normally there is not too much memory available. So that's why there is not too many C++ compilers available for these micros. I have seen C++ to C preprocessors which may be usful to do some avaluation. In short - when you write code for small processors, it is simple and to the point as there is not much time for fooling around!! Because of this, the code may not be as structured as computer scientists would like.
You may download the current Eval Version and take a look to the EC++ example projects.
C++ can have quite a bit of overhead in code and memory to support objects I think this point is usually a bit exaggerated. One of the main design goals of C++ is "only pay for what you use". While it's possible to create lots of unnecessary "overhead" -- say by declaring every function virtual whether it needs to be or not -- the programmer asks for that functionality. It's not inflicted on you unwillingly. And any decent implementation is likely to be more efficient than coding it yourself. Manually maintaining a case statement or table of function pointers to achieve the same result as a virtual function is overhead, too, plus it's extra work for the programmer. This problem is not the fault of the language, but the programmer. Template bloat? I've seen people cut-and-paste multiple K of routines rather than throw in an extern declaration in C, too. Again, it's just bad programming. You can implement templates to maintain type safety without duplicating code for every type. Some of the early implementations in the 90's also suffered from immature libraries. It took some vendors some time to implement efficient exception handling, for instance. (Take a look at the typical C program with layers and layers of error detection and return code processing, and you'll realize that there's a lot of overhead there anyway.) And early I/O libraries tended to be rather indivisible. People would get dismayed when they wrote "cout << 'Hello World'" and wound up with a 100k program instead of the 10k program they were used to from C. But that was simply the lack of 20 years of hand-tuning five different versions of printf() and stripped out unnecessary components from toy programs more than an actual problem. But in general, there's nothing particularly bloated or inefficient about C++. The language is deceptively simple, however, and is much more powerful than C. It takes a good bit more expertise in the language itself to do a good job. As with any high level language, you have to understand the real-world implementation results of what you're asking the compiler to do. 8051 architectural limitations are another problem. Even in C, you wind up programming in a subset of the language. Function pointers, for instance, are just something that the processor and tools do not handle well. That puts something of a crimp in your virtual function implementation. But, again, the alternative is coding up a run-time dispatch mechanism by hand, which is even more painful -- or, as is more likely, simply doing without. And if you're going to do without, you simply don't use the high level language feature in the first place.