Which is better for embedded work: C or C++?

[andyturk]

[...] Ofcourse you need functions to put/get/append data to the buffers because you can't have pointers directly to the memory. This is a bit clunky. With C++ you could overload the [] operator and offer indexed acces to a linked-list buffer.

That's how the original Mac OS managed memory. Every access is a double indirection and for cases when you can't do that (e.g., DMA), you have some sort of protocol for locking a block/buffer in place. You can hide it with operator[], but it's still a lot of work to go through--you're adding a constant time factor to every access.

For memory constrained devices, static pre-allocation is still the way to go, IMO. You know what all your limits are and if some resource runs short, you probably have a better chance of handling it gracefully.

Static allocations are a lot easier to test too. You can do it with a dynamic allocator, but your usage model (and your test suite) have to account for all the different permutations of allocating and freeing blocks. By the time you account for the ways in which a dynamic system can fail, you've probably spent more effort than you would to pre-allocate everything in the first place.

[kfitch42]

That is a great scheme, you have effectively recreated an MMU/Virtual-Memory in software. It is also a great fit for low level network level stuff which is all about moving streams of bytes around.

At some point that low level network code is going to hand stuff off to the 'application' layer where this type of scheme is less of a good match. Generally you will have taken that stream of bytes and transformed it into a usable structure/object. Your network layer scheme resembles my 'module A' and the application layer 'module B'. So in a simple approach their interaction can yield fragmentation. Adding the extra indirection to the network layer, which enables defragmentation definitely would help, at the expense of less determinism (in time) in allocation (which might be OK). But, once you start allowing real pointers, then fragmentation related issues could crop up.

[nctnico]

At some point that low level network code is going to hand stuff off to the 'application' layer where this type of scheme is less of a good match. Generally you will have taken that stream of bytes and transformed it into a usable structure/object. Your network layer scheme resembles my 'module A' and the application layer 'module B'.

At that point the data is usually on the stack in case of UDP. By limiting the packet size you can limit the amount of stack space needed. In case of TCP procotols like HTTP you'd need to traverse through the buffers and somehow turn the information from the headers into a more useful form.

[vvanders]

Pooled allocators are pretty common in realtime system as well since the execution cost of dynamic allocation can be pretty prohibitive(in addition to the fragmentation benefits).

[C]

How much of the code created today would fit in the the category of a work around for something limited by poor compiler or poor system.

for example, I have yet to find a processor that could not do 1024 bit integer adds or subtraction in memory. If you had the two source integers in memory and memory for the result integer you could do even larger integers, yet what languages will allow you to directly define an integer of that size and do the adds/subtracts with out having to use an add on library. Now think of how little changed the compiler generated code could be for the two source integers to be in files with the result to a file.

Now think of what you could do if you could just say create this variable or structure in a heap based file named ___ instead of the memory heap. Yes a file heap var would be slower then a memory heap var but it could hidden such that only the initial create was different in the source code. A good compiler built with this could toggle a bit or two and move all the previous compiler code structures to the heap based file so the compiler would have no max program memory size limit and end up with just a heap file space limit.

where are the IDE's that work in an interactive faction with you while you are creating source code and that if you stop for a short bit tells you that your program was compiled with these errors that are highlighted in the source code or with no errors.

C
 

[nctnico]

where are the IDE's that work in an interactive faction with you while you are creating source code and that if you stop for a short bit tells you that your program was compiled with these errors that are highlighted in the source code or with no errors.

Eclipse does that for many languages including C and C++. The syntax is checked as you type. No need to compile.

[mikeselectricstuff]

where are the IDE's that work in an interactive faction with you while you are creating source code and that if you stop for a short bit tells you that your program was compiled with these errors that are highlighted in the source code or with no errors.

Hopefully, nowhere.
That would be really annoying. You may be part way through rearranging stuff, get interruted and return to find a confusing mess of syntax highlighting.   
I know best when something is ready to compile, not the IDE.
Realtime syntax highlighting can occasionally be useful, but probably the most useful function like this is bracket/brace matching.

[C]

There are a lot of great things a great IDE could do to help.
To make mike and a lot of other people happy it should always be easy to turn on and off an option.

how many times have you looked at someone else's code looking for a side effect in a function? If the IDE had access to the internal compiler data structures this would be easy. no change in what you type would be needed.

For some types of extra help to keep things simple in the long run, some extra typing is the easy thing to allow it to happen. Back in the 80's one language I used did a lot of source error checks, Think double strict what  pascal error checking does. Not only did the bit size of a var assignment have to match, but unsigned vis signed mattered as well as the type name but all you had to do was type the following "new_type_name(old_type_var)" this told the compiler that this is OK here and still allow this error checking everywhere else.
This language really under stood what a bit is so that you could easily define in an easy to read and understand structure any thing you might find in the doc's for an F3/F4 arm processor you could easily define. Want a 4 bit var, no problem, and you could use this 4 bit var in the following. If you wanted to create a disassembler you could quickly and easily create a structure for the bits in an instruction set such that you could use a case statement in the main function of the disassembler and get compile errors if you tried to access the second register bits in an instruction that only used one register.

how about helping with the links between ISR code and Main or thread code.

A lot things could be improved and some places it has even been done in special cases but there has to be some changes made to allow it to happen more main stream.

We humans get locked up with 0 or 1 when we should be using Unknown, 0 or more.

Just my thoughts,
C

[mikeselectricstuff]

A useful feature I've only ever seen in IAR's Embedded workbench is that it automatically pulls in any included files into the project tree - this makes it very quick to check names of registers in manufacturer-supplied header files without having to dig through the install directories to find them.

I'd agree that most IDEs are fairly primitive, and have little understanding of the language - there should be a better way to find references than "find in files...".
Obviously this needs tighter integration with the compiler

[andyturk]

I'd agree that most IDEs are fairly primitive, and have little understanding of the language - there should be a better way to find references than "find in files...".
Obviously this needs tighter integration with the compiler

Meh. Keep 'em separate.

The folks who write the best compilers are usually not the folks who write the best IDEs. Except for Richard Stallman, of course (emacs is my IDE).

[nctnico]

A useful feature I've only ever seen in IAR's Embedded workbench is that it automatically pulls in any included files into the project tree - this makes it very quick to check names of registers in manufacturer-supplied header files without having to dig through the install directories to find them.

I'd agree that most IDEs are fairly primitive, and have little understanding of the language - there should be a better way to find references than "find in files...".
Obviously this needs tighter integration with the compiler

Not really. Eclipse does lots of this kind of stuff without compiling (it can understand the output of the compiler as well to show where compilation went wrong). Sometimes I have to hack bits in the Linux kernel. With Eclipse its relatively easy to navigate through the dreadfull bowl of C soup they call Linux kernel. You can even make bookmarks to remember interesting places. Want to know where the source of a function is? shift-click it and you get to that place.

[ddavidebor]

Xcode for mac suggest you a lot of things when you write the code.

[benemorius]

where are the IDE's that work in an interactive faction with you while you are creating source code and that if you stop for a short bit tells you that your program was compiled with these errors that are highlighted in the source code or with no errors.

Kdevelop is pioneering that effort (maybe xcode as well? haven't seen eclipse lately...) and I'm pleased to say it's coming along pretty nicely. A few years ago I couldn't stand using any IDE, but thanks to modern IDEs in recent years, I really can't imagine coding without one at this point.

[ivan747]

Xcode for mac suggest you a lot of things when you write the code.

Xcode is the smartest IDE I have seen in my life. It's very easy to do just about everything, and it not only knows about syntax errors and auto completion, it warns you of most errors while editing.

I found Eclipse rather bloated after looking at Xcode. IDEs are complex pieces of software, so you really have to learn one or two and stick with those.

[ddavidebor]

Yes, apple has really done this right.

[nradulovic]

I find Eclipse extremely helpful for C/C++ programming. It has reasonably nice syntax colouring, macro expansion, preprocessor conditional evaluation, various auto-completion features, code templates, code formatting, static code analysis, compile error highlight...I can't name it all.  It does take time to set it up but there are various plugins available that can save and restore Eclipse settings, so once you set it up you can easily transfer settings from one installation to another.

[kfitch42]

Since this thread has derailed into a discussion of Editors/IDEs (always an enjoyable holy war), I thought I would put in a plug for my favorite (and apparently no one else's) for doing C: netbeans. It has most of the same syntax highlighting/macro expansion as eclipse, but its subversion integration into the editor is the best I have ever seen. But, on the other hand I am quite sad that it seems to be slowly dying. When they removed python support I was quite pissed, and all the 'new' features seem to be about useless cloudy/webby shtuff (I guess some people actually care about that) or the latest try to make java a flash competitor (seriously JavaFx just aint gonna happen). Sun was mediocre crap, Oracle is serious crap.

It shows a bar down the left of the editor that has green for added lines, blue for modified lines, and a red arrow for deleted lines. Clicking on a colored section lets you revert or just copy paste from the previous version.


Last time I checked eclipse had something similar, BUT it was diffing against the last save (or something else useless like that) instead of the last svn checkin. If someone could show me how to get netbeans svn integration in eclipse I would switch in a heartbeat.

[nctnico]

If you install subversion support into Eclipse (Subversive / Mylyn) then you can compare your code against any revision and undo/redo changes. Eclipse also keeps a local history so you can go back to an older version which is quite neat if you don't use a version control system.

[HackedFridgeMagnet]

I posted a related question for you ntnico, but I thought it needed a new thread.
https://www.eevblog.com/forum/projects/question-design-descision-when-to-use-an-embedded-os-or-not/new/#new

[cthree]

The topic has shifted a bit since the beginning. Who won?

The original question is a loaded one. There are a light year of difference between an ATTiny85 and say an ARM running an OS. If the code would benefit from C++ then you should consider using it but otherwise you are better off sticking to C. When you start implementing OO concepts in C then you know it's time to switch.

The golden rule is to write as much code as you need to get the job done and then stop. Abstraction makes complex systems simpler and simple systems complex. Use the right tool for the job.

My $0.05 (no more pennies)

[legacy]

C++ may be a problematic extension of C if people are not good and methodic with it, and this may be critical for embedded devices.

[andyturk]

If you name stuff properly in C [namespaces] add no benefit, while allowing you to complicate the scope of things.

Piffle.

[millerb]

Xcode for mac suggest you a lot of things when you write the code.

Xcode is the smartest IDE I have seen in my life. It's very easy to do just about everything, and it not only knows about syntax errors and auto completion, it warns you of most errors while editing.

In my experience everything is smooth sailing with Xcode as long as your projects are straight ObjC/Cocoa. The moment you start working on non trivial sized projects with C++ libs thrown in problems start cropping up. Crashes, broken code completion and even barfed up syntax highlighting.

I found Eclipse rather bloated after looking at Xcode. IDEs are complex pieces of software, so you really have to learn one or two and stick with those.

Eclipse looks bloated compared to anything. Personally I don't find IDE's very complicated. I think a lot of what folks struggle with in IDEs is a lack of understanding regarding the underlying tools it manages for the user. Once a person understands the compilation process and all the little bits and pieces that have to work together to get the business done, the IDE ceases to appear to be this completed behemoth. And once you've learned one of the big IDEs reasonably well, you shouldn't have issues using any of the others. They're all a hell of a lot more similar than they are different.

[vvanders]

C/C++: C is almost always the best best for embedded code. You can get away with C++ if you limit the features you use and fully understand the implications, but most of what you can use is just making up for a lack of organization and discipline on the programmer's side. Namespaces are a classic example. If you name stuff properly in C they add no benefit, while allowing you to complicate the scope of things. You end up with loads of pointless getter/setter functions, sorry methods, when it would be better to just use appropriate names. For example I use _SIG for signals that must only be set or cleared and _AT for variables that must be accessed atomically for interrupt safety (i.e. turn off interrupts while accessing them).

Namespaces are a necessity when you start working with multiple codebases. Collisions are much easier, you have the ability to use aliases and other advantages. Getters/Setters will be optimized away in any half decent compiler and can be invaluable when you find out that you need then to do more then straight access.

I love C for it's emphasis on data access patterns and a bunch of other things but I would not so lightly dismiss C++. Even more so in recent days where processing power is increasing and cost for engineering is on the rise.

[andyturk]

How can I possibly disagree with such a devastating argument? Point well made, sir.

Adding to what vvanders already said...

I spend as more time integrating other people's code together as I do writing new stuff from scratch. When code don't use consistent naming conventions as you suggested, it can be difficult to avoid those name collisions. Ideally, you can just pull in a new library from version control (e.g., git) without modification. But when you have to fork/tweak library code just so it'll link with the rest of your project, it's annoying.

To be sure, it's possible to write good C/C++ code without using namespaces, but IMO it's easier to build re-usable libraries with them.