Microprocessor programming using C in an object-oriented paradigm, is it appropriate?

Since C is usually used in microcontrollers, and it is possible to do object-oriented programming in C, is it advisable to implement programming of an object-oriented microcontroller using C? What are the pros and cons?

+4
source share
6 answers

As long as you don't need polymorphism, everything is fine to convey structures. But once you use polymorphism / virtual function and placing functions inside these structures, it can become very mysterious.

It also depends on what you need to do. For drivers, you do not need OO, perhaps for an application. Keep in mind that microcontrollers have low RAM, all you need is to keep a constant amount of memory online anyway.

If you do not plan to write more than 40 thousand lines of application, just C is good enough without OO fancy tricks.

+3
source

My short answer is no. Microcontrollers are very limited when it comes to program code memory, execution speed, and RAM. It is advisable to simplify the work with C. as much as possible. C is not intended for an object-oriented language. The most that you should consider using pointers and structures, but don't try to fake polymorphism or anything like that.

+3
source

Yes, this is not only possible, but, in my opinion, sometimes appropriate.

In a small system, you should be very aware of the cost of how you decide to do something. At the same time, there may be some real advantages of "easy" orientation of objects for organizing your code, especially if you need to create flexible tools for quickly implementing settings or even for providing a hot connection. Implementing the lightest object (done, for example, using structures and function pointers) in C can be a good compromise.

Perhaps the most famous example of this is the linux kernel.

+3
source

Yes, but if your toolchain supports C ++, you would be better off using this. If the microcontroller is particularly limited in resources or the application has strict requirements in real time, you need to be rather conservative in using C ++, in particular the standard library, but you should use it nonetheless over C, if the design and implementation is OO .

+3
source

That's true, you can use OOP with C. You can also use #define to change keywords to look more like Python. However, I would not suggest doing it either.

When I saw someone trying to make a more sophisticated OOP using C, it always ends with unreadable code. When I see C code, I expect it to look like C, and not someone who knows how OOP in C should work.

If you want OOP on micro, use C ++. Many / newest microphones support it. Ignore those who say micros don't have enough memory or speed because they have no idea how fast your mic is, how much memory it has, or what your performance limits are. Well-written C ++ will beat badly-written C in size and speed any day.

+2
source

For my next embedded project, I will definitely use parts of C ++ and create a clean interface / class / static object based on the application with typedefs, it defines all the other unpleasant c. What I plan to use:

  • Classes . This allows me to encapsulate the code and unit test using stub objects using configuration.
  • Interfaces It gives me the power of a clear contract for each class compared to c header files that people tend to use as trash cans for all kinds of typedefs, and so on. In addition, the interfaces give me a separation of definition and implementation and allow me to conduct unit testing using stub objects.
  • Static objects . I do not see any dynamic memory, so all objects will be static. Probably, one application class will define and initialize everything and, thus, will be the application configuration.

In general, it will compile into something that is just as effective as with, but with a much better overview.

-2
source

Source: https://habr.com/ru/post/1333578/


All Articles