Latest Activity In Study Groups

Join Your Study Groups

VU Past Papers, MCQs and More

C++ is still useful in embedded systems. As everyone else has said, that it still depends on the system itself, like 8-bit uC would probably be a no-no in my book even though there is a compiler out there and some people do it(shudder). [ There's still an advantage to using C++ even when you scale it down to something like "C+" even in a 8-bit micro world. What I mean by "C+", I mean don't use new/delete, avoid exceptions, avoid virtual classes with inheritance, possibly avoid inheritance all together, be very careful with templates, use inline functions instead of macros, and use const variables instead of #defines. I've been working both in C and C++ in embedded systems for well over a decade now, and some of my youthful enthusiasm for C++ has definitely worn off due to some real world problems that shake one's naivete. I have seen the worst of C++ in an embedded systems which I would like to refer to as "CS programmers gone wild in an EE world." In fact, that is something I'm working on with my client to improve this one codebase they have among others. The danger of C++ is because it's a very very powerful tool much like a two-edged sword that can cut both your arm and leg off if not educated and disciplined properly in it's language and general programming itself. C is more like a single-edged sword, but still just as sharp. With C++ it's too easy to get very high-levels of abstraction and create obfuscated interfaces that become meaningless in the long-term, and that's partly due to C++ flexibility in solving the same problem with many different language features(templates, OOP, procedural, RTTI, OOP+templates, overloading, inlining). I finished a two 4-hour seminars on Embedded Software in C++ by the C++ guru, Scott Meyers. He pointed out some things about templates that I never considered before and how much more they can help creating safety-critical code. The jist of it is, you can't have dead code in software that has to meet stringent safety-critical code requirements. Templates can help you accomplish this, since the compiler only creates the code it needs when instantiating templates.

Views: 4053

Replies to This Discussion

Thanks sir!!!!!!!!!!!!!!!!!!!!

you are wright....... me agree with uuuuuuuuuuuuuuuuuuuuuuuuuuuuu.

@+º°˜`°º+Tahreem +º°˜`°º+ that is Stackexchange, not some third rated site. However, it's a resource so use it guys without taking into account who copy pasted it over here. Think for yourself the pros and cons and write down your own analysis.

yea sam zara ghoor karoo yea mere wala sol se nhe mil raha heheheheeheheh ++SAM++.....................

familiarity
desired language features
specific libraries you want to use
performance requirements

For server side programming you can often choose from a myriad of different languages, compiled or interpreted. Usually the choice of language is driven by which platform you or your team will be most effective on. Or if you don't yet have a team, the availability of skills in the market.On a side note I don't really understand deciding to use C/C++ based on performance (only) since many scripting languages are extensible with C/C++. You get the benefit of a rapid development language coupled with the ability to migrate the slow portions into C/C++ extensions. Certainly if your doing systems programming where every op counts it's understandable, but in most app development I don't get it.


C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with.C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap

c++ has an arsenal of utilities from long ago, running in many platforms. But it is painful to start walking through streams for just passing String to Integer and reverse.
C++ on the other hand, has an awful deal with dependencies on libraries. Once you compile something in GCC X or VC++ Y, then you can't rely that the code will run by the next version of those tools. The same hell is on Windows, the same hell is on Unix too.
Perl, takes its power from Unix world but especially as a regular expression tool. This is what it is used most of the time. Along with some pretty serious tools that even Java can't do it in a normal way (check out how to upload a file to a web server), Perl is "just do it".
Python is easy, flexible and a dynamic language. So easy that you can send an integer to a function, the script expects string, yet you can have a result! Unexpected though, but a result. So it the programmer needs to be very cautious. IDLE offers some debugging, but when you have TELNET'ed to a system, or SSH'ed in three levels down and you want to find your problem, the debugger won't be there to stand next to you. But, it can do some great math work fast.

pls any one can simplyfy this question that what is asked in it bcoz i m still confused about it thanx

The question is that (translated into urdu for your convenience) "Kaya C++, embedded systems ke liye sab se behtar language hei? Do you agree or not?" I know this question is a bit tricky. Well that's the matter of one's own taste. I remember creating a robot sim. Code was translated by Matlab into assembly. Because assembly is very low level language so it's better to code in C/C++. I would say, consult the 25th chapter of "Programming principles and practice using C++".

 
 


tahreem na jo jo sharing ki wo solution nei ha becareful every one

look this ya sub ak sit sa copy paste hua prove k liya muja sa contect kerin.

Yes, C++ is still useful in embedded systems. As everyone else has said, that it still depends on the system itself, like 8-bit uC would probably be a no-no in my book even though there is a compiler out there and some people do it(shudder). There's still an advantage to using C++ even when you scale it down to something like "C+" even in a 8-bit micro world. What I mean by "C+", I mean don't use new/delete, avoid exceptions, avoid virtual classes with inheritance, possibly avoid inheritance all together, be very careful with templates, use inline functions instead of macros, and use const variables instead of #defines.

I've been working both in C and C++ in embedded systems for well over a decade now, and some of my youthful enthusiasm for C++ has definitely worn off due to some real world problems that shake one's naivete. I have seen the worst of C++ in an embedded systems which I would like to refer to as "CS programmers gone wild in an EE world." In fact, that is something I'm working on with my client to improve this one codebase they have among others.

The danger of C++ is because it's a very very powerful tool much like a two-edged sword that can cut both your arm and leg off if not educated and disciplined properly in it's language and general programming itself. C is more like a single-edged sword, but still just as sharp. With C++ it's too easy to get very high-levels of abstraction and create obfuscated interfaces that become meaningless in the long-term, and that's partly due to C++ flexibility in solving the same problem with many different language features(templates, OOP, procedural, RTTI, OOP+templates, overloading, inlining).

I finished a two 4-hour seminars on Embedded Software in C++ by the C++ guru, Scott Meyers. He pointed out some things about templates that I never considered before and how much more they can help creating safety-critical code. The jist of it is, you can't have dead code in software that has to meet stringent safety-critical code requirements. Templates can help you accomplish this, since the compiler only creates the code it needs when instantiating templates. However, one must become more thoroughly educated in their use to design correctly for this feature which is harder to accomplish in C because linkers don't always optimize dead code. He also demonstrated a feature of templates that could only be accomplished in C++ and would have kept the Mars Climate Observer from crashing had NASA implemented a similar system to protect units of measurement in the calculations.

Scott Meyers is very big proponent on templates and judicious use of inlining, and I must say I'm still skeptical on being gung ho about templates. I tend to shy away from them, even though he says they should only be applied where they become the best tool. He also makes the point that C++ gives you the tools to make really good interfaces that are easy to use right and make it hard to use wrong. Again, that's the hard part. One must come to a level of mastery in C++ before you can know how to apply these features in most efficient way to be the best design solution.

The same goes for OOP. In the embedded world, you must familiarize yourself with what kind of code the compiler is going to spit out to know if you can handle the run-time costs of run-time polymorphism. You need to be willing to make measurements as well to prove your design is going to meet your deadline requirements. Is that new InterruptManager class going to make my interrupt latency too long? There are other forms of polymorphism that may fit your problem better such as link-time polymorphism which C can do as well, but C++ can do through the.

I say that all to say, that C++ has it's place in the embedded world. You can hate it all you want, but it's not going away. It can be written in a very efficient manner, but it's harder to learn how to do it correctly than with C. It can sometimes work better than C at solving a problem and sometimes expressing an better interface, but again, you've got to educate yourself and not be afraid to learn how.

This goes inline with what I have read from other embedded systems consultants. I have always been taught that with C, you cut your self in little ways constantly, but a bug in C++ is going to be more rare, but when you screw up you are going to lose a leg. Thank you for writing a clear response with some expertise that I do not have. 
I had been informed that you really need to spend time and get trained in proper techniques before charging headfirst into C++. 
On the note of Computer Science majors going crazy in EE land. At my job the worst piece of code we have was written by a CS major. We spent forever trying to teach him what the hardware was. He made a structured system using UML and built the entire system based on it in java using proper inheritance and so forth. It worked, until anything changed, and then it was a bad patch job to add features, or a complete redesign. The code is almost not usable because of how thoroughly he obfuscated the whole thing with inheritance. – 
It's not just bugs that bite you, but unmaintainable code that will bite you too. Sure, when you start that project out using those neat C++ features everything goes swimmingly, but after 2 or 3 years entropy kicks in if no serious effort is put into refactoring as you develop. That's what I'm facing right now..the code rots faster over time in C++. – 
UML and statemachines. You really need to look into Miro Samek's stuff at . He's built an efficient system that's easy to refactor and change, but it does take some time to grok it. – 
show 10 more comments
feedback

C++ is absolutely suitable for embedded systems. I now use the presence/absence of good development tools (or lack thereof) as my primary criterion for whether or not to use a particular microprocessor.

Areas of C++ that are good to use on embedded systems because they have low resource costs:

  • modularity brought by good use of classes/structures
  • templates if the compiler does a good job of compiling them efficiently. Templates are a good tool for bringing reuse of algorithms to different da

Yes, I agree.c and c++ is an optimum choice because , The reason Is that for the embedded world is because of the sheer amount of features and functions being added to alot of the different systems already in place and new systems being developed. Project get larger and larger. Either we take longer to develop them or we start applying and contorting what the CS world has already done on PCs.there are (frequently) times in embedded programming where C is not quite low-level enough language.The constructs that C++ offers over C can be put to good use in an embedded system: , exceptions, templates.

GDB Solution written by me....Change it in your own words


Embedded systems are the collection of different hardware and software's like microwave, digital watches, digital calculators, anti lock brake system in cars, etc.
There is no general yes or no. It depends on the nature of the system if it requires more logical operations then C/C++ is a good choice. It can handle low level hardware actions and properties. The Optimal choice is YES. Now a days embedded systems also use GUI so C/C++ is a better choice then other low/high level languages to code for embedded systems.

C++ is still useful in embedded systems. As everyone else has said, that it still depends on the system itself, like 8-bit uC would probably be a no-no in my book even though there is a compiler out there and some people do it(shudder). [ There’s still an advantage to using C++ even when you scale it down to something like “C+” even in a 8-bit micro world. What I mean by “C+”, I mean don’t use new/delete, avoid exceptions, avoid virtual classes with inheritance, possibly avoid inheritance all together, be very careful with templates, use inline functions instead of macros, and use const variables instead of #defines. I’ve been working both in C and C++ in embedded systems for well over a decade now, and some of my youthful enthusiasm for C++ has definitely worn off due to some real world problems that shake one’s naivete. I have seen the worst of C++ in an embedded systems which I would like to refer to as “CS programmers gone wild in an EE world.” In fact, that is something I’m working on with my client to improve this one codebase they have among others. The danger of C++ is because it’s a very very powerful tool much like a two-edged sword that can cut both your arm and leg off if not educated and disciplined properly in it’s language and general programming itself. C is more like a single-edged sword, but still just as sharp.

With C++ it’s too easy to get very high-levels of abstraction and create obfuscated interfaces that become meaningless in the long-term, and that’s partly due to C++ flexibility in solving the same problem with many different language features(templates, OOP, procedural, RTTI, OOP+templates, overloading, inlining). I finished a two 4-hour seminars on Embedded Software in C++ by the C++ guru, Scott Meyers. He pointed out some things about templates that I never considered before and how much more they can help creating safety-critical code. The jist of it is, you can’t have dead code in software that has to meet stringent safety-critical code requirements. Templates can help you accomplish this, since the compiler only creates the code it needs when instantiating templates.

………

C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said “to piss you off”, but it’s actually true. I’ve come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn’t come and screw up any project I’m involved with.C++ leads to really really bad design choices. You invariably start using the “nice” library features of the language like STL and Boost and other total and utter crap.

………

> familiarity
> desired language features
> specific libraries you want to use
> performance requirements

For server side programming you can often choose from a myriad of different languages, compiled or interpreted. Usually the choice of language is driven by which platform you or your team will be most effective on. Or if you don’t yet have a team, the availability of skills in the market.On a side note I don’t really understand deciding to use C/C++ based on performance (only) since many scripting languages are extensible with C/C++. You get the benefit of a rapid development language coupled with the ability to migrate the slow portions into C/C++ extensions. Certainly if your doing systems programming where every op counts it’s understandable, but in most app development I don’t get it.

………

c++ has an arsenal of utilities from long ago, running in many platforms. But it is painful to start walking through streams for just passing String to Integer and reverse.

C++ on the other hand, has an awful deal with dependencies on libraries. Once you compile something in GCC X or VC++ Y, then you can’t rely that the code will run by the next version of those tools. The same hell is on Windows, the same hell is on Unix too.

Perl, takes its power from Unix world but especially as a regular expression tool. This is what it is used most of the time. Along with some pretty serious tools that even Java can’t do it in a normal way (check out how to upload a file to a web server), Perl is “just do it”.

Python is easy, flexible and a dynamic language. So easy that you can send an integer to a function, the script expects string, yet you can have a result! Unexpected though, but a result. So it the programmer needs to be very cautious. IDLE offers some debugging, but when you have TELNET’ed to a system, or SSH’ed in three levels down and you want to find your problem, the debugger won’t be there to stand next to you. But, it can do some great math work fast.

………

Yes, C++ is still useful in embedded systems. As everyone else has said, that it still depends on the system itself, like 8-bit uC would probably be a no-no in my book even though there is a compiler out there and some people do it (shudder). There’s still an advantage to using C++ even when you scale it down to something like “C+” even in a 8-bit micro world. What I mean by “C+”, I mean don’t use new/delete, avoid exceptions, avoid virtual classes with inheritance, possibly avoid inheritance all together, be very careful with templates, use inline functions instead of macros, and use const variables instead of #defines.

………

Embedded systems are those systems which are copmbination of hardware and software like digital watch, microwave, mobile phones like PDAs etc. There are embaded system in some cars like anti lock brake system. So to develop that kind of systems we need to explain that whay C/C++ is optimal.

Yes, C++ is still useful in embedded systems. As everyone else has said, that it still depends on the system itself, like 8-bit uC would probably be a no-no in my book even though there is a compiler out there and some people do it(shudder). There's still an advantage to using C++ even when you scale it down to something like "C+" even in a 8-bit micro world. What I mean by "C+", I mean don't use new/delete, avoid exceptions, avoid virtual classes with inheritance, possibly avoid inheritance all together, be very careful with templates, use inline functions instead of macros, and use const variables instead of #defines.

I've been working both in C and C++ in embedded systems for well over a decade now, and some of my youthful enthusiasm for C++ has definitely worn off due to some real world problems that shake one's naivete. I have seen the worst of C++ in an embedded systems which I would like to refer to as "CS programmers gone wild in an EE world." In fact, that is something I'm working on with my client to improve this one codebase they have among others. 

The danger of C++ is because it's a very very powerful tool much like a two-edged sword that can cut both your arm and leg off if not educated and disciplined properly in it's language and general programming itself. C is more like a single-edged sword, but still just as sharp. With C++ it's too easy to get very high-levels of abstraction and create obfuscated interfaces that become meaningless in the long-term, and that's partly due to C++ flexibility in solving the same problem with many different language features(templates, OOP, procedural, RTTI, OOP+templates, overloading, inlining).

I finished a two 4-hour seminars on Embedded Software in C++ by the C++ guru, Scott Meyers. He pointed out some things about templates that I never considered before and how much more they can help creating safety-critical code. The jist of it is, you can't have dead code in software that has to meet stringent safety-critical code requirements. Templates can help you accomplish this, since the compiler only creates the code it needs when instantiating templates. However, one must become more thoroughly educated in their use to design correctly for this feature which is harder to accomplish in C because linkers don't always optimize dead code. He also demonstrated a feature of templates that could only be accomplished in C++ and would have kept the Mars Climate Observer from crashing had NASA implemented a similar system to protect units of measurement in the calculations.

Scott Meyers is very big proponent on templates and judicious use of inlining, and I must say I'm still skeptical on being gung ho about templates. I tend to shy away from them, even though he says they should only be applied where they become the best tool. He also makes the point that C++ gives you the tools to make really good interfaces that are easy to use right and make it hard to use wrong. Again, that's the hard part. One must come to a level of mastery in C++ before you can know how to apply these features in most efficient way to be the best design solution. 

The same goes for OOP. In the embedded world, you must familiarize yourself with what kind of code the compiler is going to spit out to know if you can handle the run-time costs of run-time polymorphism. You need to be willing to make measurements as well to prove your design is going to meet your deadline requirements. Is that new InterruptManager class going to make my interrupt latency too long? There are other forms of polymorphism that may fit your problem better such as link-time polymorphism which C can do as well, but C++ can do through the Pimpl design pattern (Opaque pointer).

I say that all to say, that C++ has it's place in the embedded world. You can hate it all you want, but it's not going away. It can be written in a very efficient manner, but it's harder to learn how to do it correctly than with C. It can sometimes work better than C at solving a problem and sometimes expressing an better interface, but again, you've got to educate yourself and not be afraid to learn how

RSS

© 2021   Created by + M.Tariq Malik.   Powered by

Promote Us  |  Report an Issue  |  Privacy Policy  |  Terms of Service