4

Since C is commonly used in micro-controllers and it is possible to do object oriented programming in C, is it advisable to implement object oriented micro-controller programming using C? What are the pros and cons?

ThinkingStiff
  • 64,767
  • 30
  • 146
  • 239
LEMUEL ADANE
  • 8,336
  • 16
  • 58
  • 72
  • This belongs on programmers.se. It's not specific enough to be answered here. – bmargulies Dec 28 '10 at 14:57
  • It is possible to do object oriented programming in C?? – taskinoor Dec 28 '10 at 15:05
  • 1
    @taskinoor: Yes, just like it's possible to do functional programming in Java - possible, strictly speaking, but not pretty or easy or advisable. See e.g. [Object-Oriented Programming With ANSI-C](http://www.planetpdf.com/codecuts/pdfs/ooc.pdf). –  Dec 28 '10 at 15:53
  • 2
    @taskinoor: For that matter, on my shelf is a copy of a book entitled "Object-Oriented Assembly Language".... – Brooks Moses Dec 28 '10 at 21:35
  • @delnan and Brooks Moses, thanks a lot. This is a completely new thing to me. – taskinoor Dec 29 '10 at 15:44
  • @Brooks. Can you share your copy of your object oriented assembly language book? My email is lem@email.com. Thanks in advance. – LEMUEL ADANE Jan 03 '11 at 22:44
  • @Lemuel: It's a physical book, so a bit hard to email. Used copies on abebooks.com can be had for practically the cost of shipping, though -- the author is Len Dorfman, and the ISBN is 0830634843. (Read the reviews at Amazon before you get it, though; it's entertaining, but not really written with the best understanding of object-oriented programming.) – Brooks Moses Jan 04 '11 at 21:56

6 Answers6

4

My short answer is no. Microcontrollers are highly restricted when it comes to program code memory, execution speed, and RAM. Keeping things as simple as possible with C is advisable. C is not meant to be an object-oriented language. The most you should consider doing is using pointers and structs, but don't try faking polymorphism or anything fancy like that.

Reinderien
  • 11,755
  • 5
  • 49
  • 77
3

As long as you do not need polymorpism it is ok to pass structs around. But as soon as you use polymorphism/virtual function and putting functions inside these structs it might become very cryptic.

It also depends what you need to do. For drivers you do not need OO, maybe for application. Keep in mind that microcontrolers are low whit RAM, any you will need to keep low RAM footprint all the time in any case.

If you do not plan to write more than 40k lines of application plain C is good enough and without fancy OO tricks.

Luka Rahne
  • 10,336
  • 3
  • 34
  • 56
  • Passing structs (or pointers to structs) around is not OO. It's plain old procedural programming. –  Dec 28 '10 at 15:51
  • There is so little difference between struct and class. – Luka Rahne Dec 28 '10 at 17:27
  • 1
    @delnan A struct which contains both data elements and pointers to functions which operate on that data is an object in the OOP meaning of the word. – Chris Stratton Dec 28 '10 at 17:44
  • @Chris: Yes, but structs alone aren't. The virtual methods (function pointers) make it objects. Your answer seems to imply that it would still be some kind of OO without virtual methods. –  Dec 28 '10 at 17:57
  • @delnan, I don't see how you can read an implication of "without" into a comment that explicitly contains the word "both" – Chris Stratton Dec 28 '10 at 18:00
  • @Chris: Read again. I was talking about **your answer**, not **your comment**. –  Dec 28 '10 at 18:02
  • @delnan then you should have attached your comment to my answer, rather than to my comment on someone else's answer. – Chris Stratton Dec 28 '10 at 18:04
  • @Chris: My apologies - I confused you with ralu. Corrected: **This** answer seems to imply that structs without virtual methods/function pointers are still some sort of OO. –  Dec 28 '10 at 18:09
  • Personally I'd worry more about what solves the problem well than if data-only "dumb" objects qualify as OO or if only "smart" ones containing methods do. At the point where any of it seems cryptic, one should stop - the goal is to organize and exploit aspects of commonality between things that also need to be different. If it's not helping with that, then don't do it. – Chris Stratton Dec 28 '10 at 18:18
3

Yes, it's not only possible but in my opinion sometimes advisable.

On a small system, you need to be very aware of the costs of how you choose to do things. At the same time, there can be some real advantages of "lightweight" object orientation for organizing your code, particularly if you need to make a flexible toolkit for quickly implementing customizations, or even to permit runtime hotplugging. A do-it-yourself lightweight object implementation (done for example with structs and function pointers) in C can be a good compromise.

Perhaps the best known example of this is the linux kernel.

Chris Stratton
  • 39,853
  • 6
  • 84
  • 117
3

Yes, but if your tool-chain supports C++, you'd be better off using that. If the micro-controller is particularly resource constrained, or the application has hard real-time requirements, you will want to be fairly conservative in your use of C++, in particular the standard library, but you should use it nonetheless over C if the design and implementation are OO.

Clifford
  • 88,407
  • 13
  • 85
  • 165
2

It'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 either.

When I've seen someone try to do more complex OOP with C, it always ends up in unreadable code. When I see C code, I expect it to look like C, not someone's idea of how OOP in C should work.

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

Kyle Heironimus
  • 7,741
  • 7
  • 39
  • 51
-2

For my next embedded project, I will definitely be using parts of C++ and build an clean interface/class/static object based application with typedefs, defines and all the other nasty c left out. The things that I plan to utilize are:

  • Classes. This allows me to encapsulate code and unit test with stub objects by means of configuration.
  • Interfaces. Gives me the power of a clear contract on each class compared to c header files which people tend to use as garbage cans for all kinds of typedefs, defines and stuff. Also, interfaces gives me separation of definition and implementation and allows for unit testing with stub objects.
  • Static objects. I foresee no dynamic memory, so all objects will be static. Probably one application class will define and initialize everything and thus be the configuration of the application.

All in all, it will compile into something that is as efficient as c, but with a much better overview.

Christian Madsen
  • 1,688
  • 4
  • 17
  • 30