Is object orientation bad for embedded systems, and why?

views:

460

answers:

+9 Q:

Is object orientation bad for embedded systems, and why?

Many embedded engineers use c++, but some argue it's bad because it's "object oriented"?

Is it true that being object oriented makes it bad for embedded systems, and if so, why is that really the case?

Edit: Here's a quick reference for those who asked:

so we prefer people not to use divide ..., malloc ..., or other object oriented practice that carry large penalty.

I guess the question is are objects considered heavyweight in the context of an embedded system? Some of the answers here suggest they are and some suggest they're not.

+2 A:

Nothing about 'object-oriented' is bad for embedded systems. OO is just a way of thinking about software.

What's bad for embedded systems is that, in general, they have less sophisticated debuggers, and C++ does a lot of crazy stuff 'behind your back', so to speak. Those pieces of hard-to-get-access-to code will drive you nuts.

Carl Norum 2010-07-18 05:38:37

+6 A:

What makes you say that C++ is Object Oriented? C++ is multiparadigm, and not all of the features that C++ provides are useful for the embedded market due to their overheads. (So... Just don't use those features! Problem solved!)

Arafangion 2010-07-18 05:57:23

@Afafangion: not really. How do you ensure that you stick to only some subset of C++ features ? The only way I see is not use any C++ libs at all... and it looks like a **Huge** limitation.

kriss 2010-07-19 20:58:32

But you can still use C libraries, and some C++ libraries however you'll need to evaluate them on a case-by-case basis anyway given size and performance overheads.Also, you gain strong type checking, classes, and in some cases, better optimization.

Arafangion 2010-07-19 23:07:33

+2 A:

Object-oriented design by itself isn't bad. The answer lies in your quote. Especially in real-time embedded systems, you want to make your code as light and efficient as possible. The things mentioned in your quote (objects, division, dynamic memory allocation) are relatively heavyweight and can usually be replaced with simpler alternatives (for eg. using bit-manipulation to approximate division, allocating memory on the stack or with static pools) to improve performance in time-critical systems.

casablanca 2010-07-18 06:01:24

Objects don't cost anything at all. Dynamic polymorphism does.

xtofl 2010-07-18 06:04:20

Agreed. If you keep it simple, there should be no problem.

casablanca 2010-07-18 06:09:25

+2 A:

C++ was designed with the philosophy of don't pay for what you don't use. So apart from the lack of good embedded compilers, there's no real reason.

~~Maybe CFront could have compiled C++ into C, which has a myriad of compilers...~~

Edit: The Comeau compiler transforms C++ into plain C, so the no-compiler argument doesn't hold.

xtofl 2010-07-18 06:03:39

CFront was abandoned after a failed attempt to add exception handling.

dan04 2010-07-18 06:39:17

@dan04: thanks. Another reason CFront would be helpful (exceptions in embedded code?...)

xtofl 2010-07-18 20:02:51

It a little more complicated than that unfortunately. It's unlikely you'd want to try and debug/read the C code generated by a C++ to C converter, and any debugger wouldn't display or parse it well, nor is it likely to integrate well into an IDE. It may not generate C code the compiler for the platform can cope with - for many embedded platforms, the C compiler is severely limited, and does not accept full ANSI C 89 - see the Microchip PIC16 compiler for an example, which is really quite limited in what you can write.

JosephH 2010-07-18 20:22:46

@JosephH: thanks. So it's about tooling, really.

xtofl 2010-07-19 07:51:00

the **don't pay for what you don't use** philosophy is true to some extend, but also have counter exemples. The way STL mimick pointers with iterators is one such, price is high and iterator interface suck. To see why you can read the (allready) classical article by Andrei Alexandrescu http://www.boostcon.com/site-media/var/sphene/sphwiki/attachment/2009/05/08/iterators-must-go.pdf

kriss 2010-07-19 21:14:07

+10 A:

Taking your quote at face value, dynamic memory allocation is completely separate concept from object-oriented software design, so it's outright false. You can have object-oriented design, and not use dynamic memory allocation.

In fact, you can do OO in C to an extent (that's what Linux kernel does). The real reason that many embedded developers don't like C++ is that it's very complex and it is hard to write straight-forward and predictable code in it. Linus has a good recent rant on why he does not like C++ (it's better and more reasoned than his old one, I promise). Probably most folks just don't articulate it very well.

Alex B 2010-07-18 06:04:21

IMO its not to hard to write straight-forward/predictable code in C++. The real problem is, that it is very easy to write unpredictable code in C++, while it is quite hard in C (well if you abuse the Preprocessor its quite easy in C aswell...)

smerlin 2010-07-18 12:22:48

That's not really a good rant. He just gives examples of bad code. I mean, anyone would use sctp::connect() rather than using sctp; connect(); and even if they did, you can quickly find all the usings in a file. After all, if there's not only one connect(), then it won't compile.

DeadMG 2010-07-18 13:26:59

@smerlin: Well stated. Poor programmers will produce poor results in any language.

Amardeep 2010-07-18 13:28:41

I'll always give him kudos for bringing Linux to the world. But I'd never hire the guy. Reading his rants he seems like a best practice misanthrope.

Amardeep 2010-07-18 13:33:39

@DeadMG: Aside from `using` declarations, C++ programmers (myself included) can and do just write `connect`: (1) in the `sctp` module; (2) when `connect` is a member of the current class or a base class; (3) (more rarely) when `connect` will be found by ADL. C++ has more complex name lookup than C. It's not "bad C++", or unusual, to use that, but there are many cases where more than one `connect` exists, and the code compiles. Maybe Linus's needs are specialised, this reason for avoiding C++ is specific to him, but I think the point is fair. It would apply to any language with virtual calls.

Steve Jessop 2010-07-18 14:08:14

... and for that matter it applies to C code which emulates virtual calls with arrays of function pointers, in parts of the Linux kernel. As soon as you're calling a function by address, you can no longer grep for the call destination as Linus requires. Still doesn't mean it's bad code, just that sometimes his preference must be sacrificed for functionality.

Steve Jessop 2010-07-18 14:09:57

I very much like a couple of linus' posts in that thread. It is indeed true, in my opinion, that c++'s pass-by-reference, for example, is often very inappriate, and really not "safer" than pointers. The latter of which are really much more clearer to the caller. And i also agree with him about the specs being way clearer and for C, and about some C++ "specialists" that propose doing any and all things using templates so it's more "generic" - don't like that either.

Johannes Schaub - litb 2010-07-18 19:08:10

@Amardeep: Nearly all open-source activists are arrogant misanthropes. Look for Ulrich Drepper, GregKH, Theodore Ts'o etc., you'll always find the same pattern: No company would ever hire them except for the OSS companies. Shuttleworth and de Icaza seem to be two of the very few OSS people with basic social competence.

Philipp 2010-07-18 20:30:20

+1 A:

Programming is always about using the right tool for the job. There are no pat answers, and that is especially true in the embedded world. If you want to become skilled in embedded development you will be just as intimately familier with C as you are with C++.

Tergiver 2010-07-18 13:22:33

+6 A:

Whilst I'm not sure it answers your question, I can summarise the reasons my previous companies source code was pure C.

It's firstly worth summarising the situation:

we wanted to write a large amount of "core" code that would be highly portable across a large number of ARM embedded systems (mostly mid-range mobile phones; both smart phones and ones running RTOSs of various ages)
the platforms generally had a workable C compiler, though some for example didn't support floating point "double"s.
in some cases the platform had a reasonable implementation of the standard library, but in many cases it didn't.
a C++ compiler was not available on most platforms, and where it was available support for the C++ standard library, STL or exceptions was highly variable.
debuggers often weren't available (a serial port you could send debug printfs to was considered a luxury)
we always had access to a reasonable amount of memory, but often not to a reasonable malloc() implementation

Given that, we worked entirely in C, and even then only a restricted set of C 89. The resulting code was highly portable. We often used object orientated concepts though.

These days "embedded" is a very wide definition. It covers everything from 8 bit microprocessors with no RAM or C compilers upto what are essentially high end PCs (albeit not running Microsoft Windows) - I don't know where your project/company sits in that range.

JosephH 2010-07-18 20:37:24

+1 A:

As others have noted, 'embedded' encompasses a broad and varied range of hardware/software options. But...

The quote you give will give microcontroller embedded types shivers. Dynamic allocation is a no-no, if you have an error, you crash the system in unpredictable ways. Divides are heavily discouraged since they take forever in execution time. Objects are only discouraged insofar as they tend to carry lot's of 'stuff' around with them, all that 'stuff' takes up space, and microcontrollers don't have any.

I think of embedded as being projects that are small and specific, you don't worry much about extensibility or portability. You write clean code in C that does only and exactly what you want your device to do, reliably. You choose one chip family so you can move your (almost the) same code among different hardware options with minor tweaks to the port your writing too or initialization of configuration fuses.

So, you don't need to define

4 wheeled Transportation
Car
Toyota

Since you're only working on Toyotas. And the difference in accelerations between a Camry and Corolla are stored as constants in a register.

ArielP 2010-07-19 19:15:16

ansaurus

tags:

views:

answers:

Is object orientation bad for embedded systems, and why?

related questions