C vs C++ in Embedded Systems?

I see this justification a lot, and in conventional sequential code it makes sense. However, anytime I run into these issues I wrap the throw scope in a state machine, and put the error check in *one* obvious place. The overhead of "explicit error checks everywhere" doesn't apply. I don' need no steenking exceptions ;).

Going back to the (most) recent discussion about RTOSs: I'm wary of the design approach that figures there's another layer watching out for my ass. Diapers don't make for good housetraining.

Steve

formatting link

Reply to
Steve at fivetrees
Loading thread data ...

C++ specifically or OO in general?

There's a good deal of sense in encapsulating (i.e. decoupling) e.g. a comms driver and(/from) the rest of the application. But that's just good, sensible decomposition. I don't believe there's anything inherent in C++ that changes/enhances this.

Steve

formatting link

Reply to
Steve at fivetrees

And an idiot writing in assembly is somehow better?

That's interesting. I've fixed idiot PL/M-96 code. It doesn't matter _what_ the language is -- I've found idiot Ada code, and I'm not even an Ada programmer (great fun: them: "our code is in Ada, the language of the gods, it can't possibly have bugs" me: "what's this discrepancy between line 123 and line 154?" them: "oh sh--").

Everything I've done in C++ has been in high-end 16-bit and low-end

32-bit processors. I probably wouldn't use it on an 8-bit processor unless I had compelling reasons.
--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Me too.

For *real* object-oriented coding, C++ is a bastard, it's not a super-assembler (like plain C), nor a real object language (like Eiffel, Java & co).

The real problem with embedded C++ is the non-transparency of the language: a seemingly innocent piece of code may generate a translated code behemoth.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

My philosophy is, "don't inherit it, cut and paste it into the source!" This allows code reuse in Assembly Language, Forth, BASIC, and yes, even in C++.

Guy Macon

Reply to
Guy Macon

HEY! What about *my* favorites; 4-bit CPUs with 64 nybbles of RAM?

Not a lot of call for C++ on those... :)

Reply to
Guy Macon

I use Nucleus Plus Plus, which is an OO wrapper around a C-based RTOS. It makes working with the RTOS a pleasure.

--Gene

Reply to
Gene S. Berkowitz

Isn't this also the case for C library functions or even assembly language macros? In all cases, the solution is to know your tools very well. C++ gets to be "transparent" when you become an expert with the language. As with C compilers, if you're in doubt, look at the generated assembly. It's actually pretty easy to avoid code bloat in C++ if you're careful. For instance:

- avoid virtual base classes

- don't use multiple inheiritance

- avoid templates where practical

Modern C++ compilers tend to be pretty smart if used wisely.

Ed

Reply to
Ed Beroset

Sure. But you know when you're calling a library function, and you know what the code in the library function is.

Same answer

The problem is that the C++ language it's several orders of magnitude more complicated than most other languages. 99% of the people writing C++ aren't experts in C++. It far easier to be an expert in C. Or Python. Or Modula-3, or Ada, or Pascal, or ...

But they aren't.

--
Grant Edwards                   grante             Yow!  PEGGY FLEMING is
                                  at               stealing BASKET BALLS to
 Click to see the full signature
Reply to
Grant Edwards

Don't be so sure. As an example, consider the C language fragment:

int numerator = 35323; int denominator = 1038; int answer = numerator / denominator;

On an 8-bit micro with no native divide instruction, this can generate quite a bit of code even though there was no obvious library call. Obviously, for that kind of micro, C++ would have the same problem.

And same response! For an extreme example see HLA.

formatting link

Nobody uses all of the language, so you don't have to be expert in all of it -- just the subset that you use.

That's true, but if you're tackling a job with C++, it's often of the larger and more complex variety anyway, so you can either become expert on your own implementation of the system in C (which is fairly useless on the next job) or become expert on a complex but powerful language like C++. Just for scale here, when I say "larger and more complex," I'm thinking of embedded projects that would be more than 100k lines of C code.

Automobiles tend to kill people because most people aren't expert drivers. Therefore everyone should avoid driving. That's sage advice, but you need to evaluate both the cost and the benefit. Weighing the risks and mitigating them by improving your own skills, there are many transportation problems for which an automobile is a good answer because the benefits outweigh the risks, just as there are many programming problems for which C++ is a good answer because the benefits outweigh the risks.

I don't say that everyone should always use C++, but I think it's equally poor advice to say "never use C++ for embedded systems."

Ed

Reply to
Ed Beroset

But on an 8-bit micro with no native divide instruction, the "/" is an obvious library call. Just as any floating point operator is a function call on a processor without FP hardware.

But there are plenty of powerful but simple languages that would work just as well. Power != complexity. It's a shame that an entire generation of developers seem to think that to get the benefits of OO you have to use a complex language like C++. C++ is just plain badly designed. It's overly complex, and it's dangerous. Neither of which are required to get the benefits of encapsulation and OO.

--
Grant Edwards                   grante             Yow!  I'm meditating on
                                  at               the FORMALDEHYDE and the
 Click to see the full signature
Reply to
Grant Edwards

Well said. That's exactly my viewpoint in all respects.

Reply to
Steve at fivetrees

Yeah, but so was Erlang, and it's an OO-functional language with all the usual ML-style garbage collection facities. So I don't think that's a great argument...

--
Andrew
Reply to
Andrew Reilly

My understanding is that STL relies heavily on using dynamic memory.

In small embedded/realtime systems (not using virtual memory), using dynamic memory can cause severe memory pool fragmentation, which would case a memory allocation failure sooner or later. In systems designed to run continuously for decades (or until the hardware is replaced), the use of dynamic memory can be a quite critical question.

Paul

Reply to
Paul Keinanen

Actually, that just bolsters the argument -- real time systems can be built in a lot of different ways, including with C++.

Ed

Reply to
Ed Beroset

My understanding is that there are modern coping garbage collection systems (for languages that don't mind having things move around at run time[*]) that are supposed to not break as long as there is at least twice as much physical memory as the worst-case active memory load. So if you're prepared to pay that price (allocate no more than half of available memory at once), you should be able to use dynamic memory and garbage collection "forever". I know that Eiffel has been used, with such a garbage collector, in some ample-memory embedded systems, like laser printers.

[*] That's pretty much the "safe" languages that don't let you muck about with pointers as though they were integers, or make up pointers with integer maths: the lisps & schemes, the Pascal family (including ADA? dunno) and Eiffel, the ml family, Java, C#, etc. Almost the set {not C, C++}...
--
Andrew
Reply to
Andrew Reilly

Do you mean that it makes no sense to throw exceptions in state machines? If so, why?

Why are state machines different? An action could very well make a deeply nested call, or could it not? So, it makes sense to use exceptions there.

Regards,

--
Andreas Huber

When replying by private email, please remove the words spam and trap
 Click to see the full signature
Reply to
Andreas Huber

Hi, I have personally used C++ for an embedded system which is used in a consumer electronics appliance.We used C when it requires Hardware interaction and C++ in the application level to generate UI,Menus and stuff like that.Really We enjoyed the reusability feature of C++ and did not see any performance problems though.I would prefer a mix of both ,though depending on the system.If you really want reusable code and want to maintain good maitainability in the code in the application perspective(though not on h/w interaction),I feel C++ will be your best bet.I raised the same query a few days back and was informed,instead of blaming the language,better learn the language to use efficiently.I till now have the same opinion.Any language can be used to best way it can work,if you know how to use it efficiently.If you feel it does not fit your application,it does not mean,the total language is useless!I believe totally rejecting C++ for embedded is not a fair judgement.

P.S:I have no experience with other OO languages,so I will restrict my opinion only to C++.

Regards, s.subbarayan

Reply to
s.subbarayan

This is most obviously a taste issue. 8-bit processors can be whipped to do amazing things, but considering the simplest example, like a PWM generator, then OO design technique feels a bit like overshoot. To each by their taste, however :)

At least we agree on something :)

-Antti Keskinen

Reply to
Antti Keskinen

In order to be able to move the dynamic objects, the object can not be accessed directly through pointers. Each object must be accessed with a handle, that is used to index a pointer table to get the final address.

The required indirect indexed addressing mode can be quite costly depending on available addressing modes and available registers and will cause an increase in code size. Also each active object needs a pointer in the pointer table, which must be in RAM, since the dynamic memory manager must be able to update it, when a data block is moved (reshuffled).

However, in embedded and/or realtime systems, there are often interrupts and task switching, which are quite problematic, if dynamic memory objects can be moved. You either have to disable the interrupts during dynamic memory data moves, which often is unacceptable due to the long latencies or the interrupt service routines _must_not_ be allowed to access any memory allocated dynamically.

Even if the dynamic memory reshuffling is done in the lowest priority (NULL) task, in a pre-emptive OS, an interrupt can cause a high priority task to become runnable, which should suspend any lower priority tasks. However, if the dynamic memory reshuffle is in progress, this task switching must be disabled, until the reshuffle is completed, which may delay the execution of the runnable high priority task longer than acceptable, even if a single block is reshuffled at a time.

Suggesting such huge extra allocations would not be very realistic in many embedded systems with low resources.

Paul

Reply to
Paul Keinanen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.