C++ in embedded software programming [closed]_问答_开发者

开发者_运维问答 It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 10 years ago.

Is there significant problem, if I write the code for embedded linux system using C++ language programming ?.

Actually, I have intention to port some code to arm linux, with arm-uclibc compiler.

Thanks

As I read your question, I was thinking about traditional embedded programming until I saw the Linux part. C++ can be used in embedded programming with caveats around hidden constructors, etc. If you're running Linux, I suspect that you don't need to worry about that stuff.

Are you asking about plain C++ or embedded C++? As I understand it, embedded C++ is pretty much dead. You can program in C++, but, depending on your requirements, there may be some constructs that you will want to avoid using. For example, if you don't have much space, you may want to avoid templates as much as possible (or to explicitly instantiate templates) to keep your template instantiations to a minimum. You might also want to avoid exceptions or RTTI to reduce the amount of generated type information (to save space) and also to avoid having to deal with exception safety (to keep potential pitfalls to a minimum) as well as the high cost of exception propagation (to shorten the longest execution path, for real time systems). Virtual functions should be OK (they don't introduce that much overhead), but if you have very strict requirements, you may also need to limit your use of those. If you do use exceptions, you should also be sure that the compiler supports them (as many cross-compilers for embedded systems do not).

Porting large software might be troublesome. I have experience programming 8-bit motorolla microcontroller with gcc c++, but in my case I started from scratch, so it was easier. There were few problems I encountered, like using destructors stopped program from executing, and not taking care of call-stack would cause it to overflow over other program variables...

So, my advice for writing c++ code on embedded device, is not to do many changes at once. When you program in small increments it's easier to spot when something stops working because of buggy compiler or hardware.

I think using Linux in an embedded system is more questionable that using C++. In the sense that it is a more significant decision rather than necessarily a bad idea.

Most of the concerns relating to C++ in embedded systems are to do with code size and performance; many of the concerns are based on myth or are far less significant that you might think, but even where they have some justification, they pale into insignificance compared with the overheads of running Linux and the unsuitability of the Linux kernel for hard real-time and low latency applications.

I regularly use C++ in embedded systems on OS-less and RTOS based systems. Use of Linux is justified where real-time deterministic behaviour is not required but the device, filesystem, and networking support provided is useful (although much of this is achievable in other ways), and your system is endowed with significant resources; but it would always be last on my list of choices for an embedded system OS if there were no compelling requirement.

If you choose to use uClinux on an ARM with no MMU (an ARM7 or Cortex-M3 for example), then you loose a significant compelling reason for using Linux in the first instance - MMU protected processes/kernel.

Is there a significant problem?

It depends on how you program. If you comment liberally, and organize your code well, then no - you won't have problems.
It depends on the debugging capabilities of your development environment. If it is not easy to use, you will have problems tracking down bugs.

If I'm not mistaken, arm-uclibc is a C compiler?