Hi arnuld, Your questions are a bit off-topic for this forum. Not saying that to chastise, rather that you may get more answers of better quality on a more appropriate forum. That being said... > At the company where I work, its decided by higher authority that we > will use C since our software will run on some embedded platforms and > for embedded platforms C++ is not a good idea. I have done embedded programming with C and C++. Long time ago. Your company's higher authority is not "wrong", per se. C++ for embedded platforms has some sharp, sharp edges that are generally unimportant on (say) a personal computer, workstation, minicomputer, mainframe, or supercomputer (except for the tight blazing performance sections). The sharp edges with C++ that can make it a poor choice for embedded programming are (as I vaguely recall): + exception handling and RTTI can be too much overhead (in my situation, we used the compiler flag to disable exceptions and RTTI) + I/O streams? ha ha ha ha ha ha + template magic can balloon the footprint There may be other considerations too, which I have forgotten, or can't recall at the moment (haven't had my caffeine dosage yet). All of the above can be mitigated by having very skilled C++ developers, who are aware of the potential pitfalls of C++ in an embedded platform. And they conscientiously avoid those pitfalls, and have a rigorous testing and checking build system to ensure that something didn't sneak in and cause things to go all pear-shaped. But that's the trick... having very skilled C++ developers. And if you have very skilled C++ developers, it is not unreasonable to assume that they are also very skilled C developers. For an embedded platform, C has less surprises, and requires less rigorous diligence to avoid the C++ pitfalls in an embedded environment. In my experience, I think of C as a very pleasant macro-assembler language (I came to C from an assembler background in 6502 and 680x0). Whereas I think of C++ as an object-oriented language and an EXTREMELY AWKWARD code generator language (i.e., template magic). I've been programming in C++ since 1990. > Reading Stroustrup's FAQs tells me the opposite: > http://www.research.att.com/~bs/bs_faq.html Given very skilled C++ developers who have mechanisms in place (code reviews, automated build checks to detect unexpected binary footprint growth) to prevent C++ pitfalls going undetected... sure. What is *NOT* a reason to avoid C++ are these not-true-isms: + C++ is slower than C [bzzzt, wrong] + C++ has a bigger footprint than C [bzzzt, wrong] (It's a DANGER, but not an /a priori/ given) Good C++ should match/rival good C, in terms of both footprint and performance. I would not expect good C++ to surpass good C, nor vice versa. But, in my opinion, good C++ will be more maintainable than good C -- which becomes an important factor if the code base becomes very large. I do not expect that the code for an embedded project to become very large, so I do not expect that the C++ maintainability factor (assuming my admitted bias in favor of C++ has merit) to be a significant factor. And, of course, bad code can be written in any language. All bets are off if your comparison is bad C++ versus bad C. > I am implementing a Priority-Queue (PQ) in C but I see C++ already has > a template, a generic PQ implemented in Std. Lib. Hence I am not much > interested in code-duplication, I am not interested in doing a work > which has already been done in a much better than I will ever do. We > are using gcc for our embedded platform, now I don't get it if gcc > works on embedded platform then why can't we use use g++ ? I'm GUESSING that your higher authority either is concerned that the developers are insufficiently skilled C++ developers, and as such, would inadvertently create C++ code that was either slow, and/or had too large of a footprint, and/or relied on otherwise available C++ mechanisms that will be disabled for an embedded environment. > The embedded platforms we are working on will mostly be *NIX or much > less vxWorks and very rarely something Windows based. In my experience, writing portable C++ for a variety of Unix, Windows, and Macintosh platforms, C++ can be portable. But it isn't "free" or automatic, the team has to be conscientious about portability issues. And -- my goodness -- there are a lot of portability gotchas. > Has anyone worked on embedded platforms before, may be he can tell if > we can use templates over there and any other information will be > appreciated. Yes, in my embedded platform code, we used templates. A *lot* of templates. (We used a homegrown work-much-alike and inspired by Douglas Schmidt's ACE, which is strongly template driven, as was our homegrown framework.) The trick to preventing the binary footprint from ballooning, but still having most of the advantages of C++ and templates, was to separate out common code from the template, so that the template was a thin veneer over code which handled void* parameters. The template goo would often disappear (optimize away), or be a very thin springboard routine to the heavy lifting non-template void* parameter driven code. We got static type safety, and template generic programming. And a small footprint. We did have to give up on C++'s dynamic casting, exception handling, and RTTI. Sincerely, --Eljay
