C90 vs C99 vs C++ for Cortex-M

[richardman]

Just out of curiosity, how many people write in these dialects of C/C++ languages?

In case you are not sure. If you use interspersed declarations / statements, designated initializers, and variable sized arrays, then you are using C99.

Most/all vendor libs are mainly C90. nRF SDK uses C99 features. No vendor libs (asides from mBed?) use C++ that I know of.

Thanks

[jnz]

Market research time?

The question you ask is "how many people"... I think you wanted a poll not a normal post.

[richardman]

Well, I don't think a poll of EEVBlog forumers is sufficiently large for a "scientific" poll. However, anecdotal replies may be illuminating ("I will chew my left toe off before I use C++!" "You are a garden gnome if you still use C!" etc. ;-) )

[coppice]

You didn't list any dialects of C++, and you didn't list C11.

I don't understand why so many people are still stuck in the C89/C90 world. That's a long time ago, and C99 has a number of things which make embedded work cleaner. Just having the inttypes.h header, to provide standardised named for different word length integers, can be a real boon. C11 is already 4 or 5 years old. Its time we started making use of the new stuff it provides.

[richardman]

You didn't list any dialects of C++...

If there are enough people using C++, that would be my next question. Thanks for answering.

[obiwanjacobi]

Although I am not a STM32 programmer (yet) I use a subset of C++ for AVR stuff (see my lib in signature). I have been a programmer for over 25 years and I think about software in OO terms. I recently had to do some C and I really needed to shift my mindset.

I find (my opinion) that it allows me to make the cleanest API while still compiling into pretty optimal code (assembler). You have to be real careful what C++ features you use, though. I mainly use C++ templates to allow as much flexibility as possible and as much hard-coded constants as possible, the result of the need to save RAM. This was born out of my frustration with the structure and quality of the Arduino stuff (that's were I started).
However, I find it also very hard to find the correct patterns/structures for the peripherals and give all the options they support a logical place in that API.

[Jeroen3]

ARMCC (5.03 at least) does not support C11. The latest it supports is C++ 2003.

[richardman]

... You have to be real careful what C++ features you use, though. I mainly use C++ templates to allow as much flexibility as possible and as much hard-coded constants as possible...

Very interesting comment that westfw also mentioned in another thread. I do think that the basic template idea seems to be a good abstraction for writing generic functions.

I just found a document on the web that the author of lcc-win32 (which was derived from LCC, the C90 front end) has evolved / proposed some featyres that not not in C99/C11 or C++ that may be interesting, including operator overloading, reference, and generic functions.

A study of C longevity shows that code that was written 25-30 years ago, look remarkably like code that are written today, which contributes to its continued popularity - it's good, basic, and works. I guess a little bit like using an old camera (I even use a 4x5 large format camera :-) ) vs.  digital cameras

[westfw]

how many people write in these dialects of C/C++ languages?

I was a bit shocked to discover that some features I used and relied on in C "for ages" are actually considered C++/C99 "enhancements."  (inline functions, for instance.)

Arduino uses C++, though not nearly as much as it might (no templates in the arduino libraries, AFAIK, for instance.  And some of the objects are not well implemented (IMO, without being a C++ programmer.)) (probably it's most important as an existence proof that you can run a "useful" c++ program on a microcontroller with 7k of flash and 1k of RAM.)  (A bunch of the "typical" articles on why embedded programmers should be using C++ start out with "there I was with my 72MHz 32bit ARM Microcontroller with only 512k bytes of flash...", making them a bit difficult for 8-bit expert to take too seriously.  (followed by "virtual functions only cause an extra pointer dereference or two."))

A study of C longevity shows that code that was written 25-30 years ago, look remarkably like code that are written today

I have some 30y-old C code aimed at workstation class machines ((The MM mail reader ported to unix, with TOPS20 COMND%-like cli parser.)  It's AWFUL!  Full of OS-dependent conditional compilation for BSD/SYSV/MSDOS/SUN/HPUX and similar.  No function prototypes and old style function definitions, too, but the OS issues are the most painful.  Things are somewhat better now, post-posix and now that PCs have "grown up.  (But you can still look at some of the things that automake checks for; I've built stuff from linux source for non-linux systems; I usually call it time spent in "dependency hell."  Shudder.  (mostly not actually language issues, though (and most of it is relatively easy to "port forward", compare to what it must have been like to work on originally.)

[nctnico]

GCC uses the GNU and C11 (2011) standards by default.

[rstofer]

I have no idea which version of plain old C I use.  It's just C...  It isn't K&R C because the function definitions are different.  It isn't C++ because - well, I've never seen the utility of object oriented programming for embedded processors.  When I think about embedded programming, I come to the conclusion that I don't want things happening willy-nilly, by magic.  I don't want constructors and destructors.  More importantly, I don't want a heap or a heap manager.  That means I have to write my own string functions (copied from K&R) and use a substitute for printf().  Done well, a heap manager is a very complex thing when you consider garbage collection.  This is not the kind of thing I want in an embedded processor.

BTW, the Linux kernel is written in C, not C++.  I have no idea which version of C because I never looked.  I'd be willing to bet it's just plain old C.

[nctnico]

Sorry but the standard library doesn't use alloc/malloc so you can use those functions without problems. You wrote your own strings functions for nothing!

The difference in C standards is in things like being able to use variable sized arrays (those are kept on the stack) and initialising structs using the member names.

[djacobow]

I used to worry about using dialects of C and C++ that would might not be supported on some platform that I might be using in the future. Then, I realized that or at least the last 15 years I had never used a commercial compiler -- it's been gnu all the way. At that point I learned to stop worrying and love the modern dialects like C11 and C++11 that gnu has always supported years before most proprietary offerings.

Regarding the efficiency of C++ on embedded platforms, I think it's true that going crazy with vtables can get expensive, but I usually restrict myself not to use polymorphism in resource tight projects. Yeah, that's giving up a big feature of OO, but it's not the only feature.

I have really mixed feelings with C++. I think it is an embarrassingly large and complex language, with so many subtle ways to hurt yourself. But it is powerful and expressive. In the end, I use it and would be unhappy sticking to C89 or somesuch.

Furthermore, regarding vendor (and other libraries), everyone uses C interfaces, and that's very understandable for a lot of reasons, but it's also kind of a shame. It would be cool to use some libraries with c++ interfaces. I have worked on projects where some important library was written in C++, delivered as a .a + header files, and my code was c++, too, but of course, calling between the library and my code was "extern c." Somewhat sad, IMHO.

[Yansi]

I write mostly in C90, sometimes C99.  Object oriented rubish... meh. 

[dferyance]

I write mostly in C90, sometimes C99.  Object oriented rubish... meh. 

It is a myth that C++ is OOP. It picked up popularity during the time that OOP was becoming popular and started out as adding OOP features to C. But that is very old history and the language has moved on quite far from that. Many of the people who really push OOP don't like the way C++ supports it either. Just consider the STL, like it or hate it, but it is very non-OOP. In some of my C++ projects, by-far most of my "classes" are not for defining OOP objects but for doing things like type-traits or data structures.

Just the added type-safety and new-style casts in C++ are nice. The language tries to not provide features for programming a specific way but general-purpose features that can be used multiple ways. It also is very good that you don't pay for features (in performance or space) that you don't need or use. Lots of programmers forget to mark their destructors virtual but the whole idea is that you don't introduce vtables that you don't use. So be smart about how you use it and it works great on embedded systems.

The down-side to all this is it makes the language complex. You don't have to use it a certain way but that means you can use it any way you like; including other programmers using it in ways you didn't expect.

[nctnico]

I used to worry about using dialects of C and C++ that would might not be supported on some platform that I might be using in the future. Then, I realized that or at least the last 15 years I had never used a commercial compiler -- it's been gnu all the way. At that point I learned to stop worrying and love the modern dialects like C11 and C++11 that gnu has always supported years before most proprietary offerings.

Same here! Which is why I recommended Richard to look at what GNU does. As a small compiler maker you have to go with the flow.

[rstofer]

Sorry but the standard library doesn't use alloc/malloc so you can use those functions without problems. You wrote your own strings functions for nothing!

The difference in C standards is in things like being able to use variable sized arrays (those are kept on the stack) and initialising structs using the member names.

I have forgotten which functions in the ARM incantation called _sbrk but whatever they were, I don't use them anymore.  There just isn't a heck of a lot of string work in embedded programming - at least not for the stuff I play with.  I need itoa(), of course, and that drags along reverse() then add in a few of the simple functions from K&R and it's done.  Just include the same source file for the next project.  This is not a huge effort.

For debugging, I usually dump numbers as hex strings of various widths (8,16,32 bits) and I just build up the string with a couple of functions and pass them along to puts().  I am almost always making something for running hardware, not solving world hunger.  There may not even be a display in the final product.

The very first code I write will get the UART running.  Well, maybe after I blink an LED...  Most of my debugging is done with print statements and very little with JTAG and GDB.  I do like the Rowley Crossworks toolchain for ARM projects but my last couple of projects used an mbed and it doesn't lend itself to JTAG debugging.  Besides, I got worn out on single stepping way back with the 8080 and 8085s.

But I still don't know what version of C I use.