Software for embedded systems in OOPs

[pairofstrings]

Hello.
If Linux is completely written in C(?) then I need a strong reason to opt for OOPs for Embedded Systems software.
Can anybody tell me a situation or a circumstance that would make me use Object Oriented Programming principles to write software for Embedded Systems?
Thanks.

 

[Mark44]

Hello.
If Linux is completely written in C(?) then I need a strong reason to opt for OOPs for Embedded Systems software.

Can anybody tell me a situation or a circumstance that would make me use Object Oriented Programming principles to write software for Embedded Systems?

Thanks.

I can't speak from experience about Linux, but when I worked in the Windows Division of Microsoft some years ago, Windows was written to a large extent in C++ (using little or no OOP features), and C, with a little assembly thrown into speed up certain operations such as graphics rendering. My last 10 years there I worked in a different division, so I didn't have access to the Windows code base. I imagine that a fair amount of Windows outside of the kernel is now written in C#, but don't know that for a fact. I would guess that Linux is probably similar, but without the C#.

I don't have any experience working with embedded systems. From what I've read, programming them is done predominantly in C and/or C++, without much done using OOP capabilities. In times past, the programming was done exclusively in assembly language, for several reasons -- nonexistence of cross-compilers for the architecture of the embedded system, limited resources for the processor in terms of RAM and ROM, and the need for code to be highly optimized to run as fast as possible on chips with slow clock speeds. These reasons make OOP programming a non-starter.

 

[surepic]

OOP is the way of thinking, code in C# or other non suitable for embedded system can be translated to C or C++ and be used in embedded system. Main difference in embedded system is to avoid heavyweight operations like division, floats, etc. Instead we are using bitwise operations, switching from floats to integer math, and always calculating how much resources will be consumed and what will be left for other functions to use. Slow clock isn't issue I never got into trouble with slow clock speeds the major problem is limited memory. But after some time you are getting used to making several lines of codes into equations then trying to use bitwise operations like bitshifting left/right to get the same result with less lines of code in less cycles.

 

[FactChecker]

Just talking in generalities:
Real time embedded systems can use C++ and OOP, but you have to be careful about which aspects are used. Most people would probably consider it to be a limited OOP. In systems that are safety critical, there are additional restrictions.

That being said, even with the restrictions, OOP can be helpful in keeping a large software program organized, systematic, and logical. However, there is a danger of over-using some OOP features that are intellectually satisfying but have practical problems.

 

[|Glitch|]

C++ was developed in 1987 specifically to deal with OOP because C couldn't. Unfortunately, neither are structured languages like Pascal. However, the majority of the planet decided to use C and C++ for its flexibility, structure be damned. Even though this flexibility would end up causing lots of problems with programmers who were not trained to develop structured code.

The reason C is not intuitive is because it is a third generation language. Just one generation removed from assembly code. Just imagine if scientists had to write their programs in assembly. I would pay to see that. (It might give them new appreciation for us developers. )

C++/C#, Java, Python, Ruby, etc., are all fourth generation languages, and therefore much easier to understand and use. If you are using any of these fourth generation languages then you are already using OOP, whether you realize it or not. OOP is not merely a philosophy, it is a completely different development methodology, which is why new languages had to be developed specifically for OOP.

While Borland, and everyone else, was creating C++ in the late 1980s, Microsoft took a slightly different approach. They developed OLE and COM, which were OOP models that their third generation languages could access. Remember "Drag & Drop?" They eventually came around to developing their own C++ by the early 1990s though.

That is the real problem with programming languages today. When you had to develop applications in either assembly or a third generation language you had a better understanding of what was actually happening. You knew in more detail how the command you gave was being handled by the compiler. With today's fourth generation languages we are removed from the inner-workings and therefore do not have as good of an understanding of how a command is being dealt with by the compiler. The up-side to fourth generation languages is quicker development time and much more complex applications. The downside with fourth generation languages is that the more generations you are removed from machine code, the slower the application runs and more problems will arise. The slow execution speed of the software can be offset to some degree by the speed of the hardware, so the downside really isn't that bad.

 

[newjerseyrunner]

Linux is not written in C, the Linux kernel is written in C. Drivers, utilities, programs... tend to be written in c++. C++ allows for inline assembly, which makes it easier to write low level stuff. I’ve written plenty of c++ for embedded systems, you just have to optimize your code a certain way and not use things like the standard template library or boosT.