-1
\$\begingroup\$

What would be the pros and cons of using C++ over C for uC (AVR) programming ?

\$\endgroup\$
  • 2
    \$\begingroup\$ I would say that "lack of C++ code for accessing uC facilities" is the big one. \$\endgroup\$ – Ignacio Vazquez-Abrams Oct 17 '12 at 14:42
  • 2
    \$\begingroup\$ @IgnacioVazquez-Abrams: don't think there exists a C++ compiler that doesn't allow you to call external C functions, so this is not really an issue. \$\endgroup\$ – Dave Tweed Oct 17 '12 at 15:02
  • \$\begingroup\$ But at that point you're not writing C++, you're writing C-with-classes. \$\endgroup\$ – Ignacio Vazquez-Abrams Oct 17 '12 at 15:07
  • 1
    \$\begingroup\$ @IgnacioVazquez-Abrams: I don't understand your point. There's nothing about calling an external function that prevents you from using any/all of the features of C++. See Wouter van Ooijen's answer below. \$\endgroup\$ – Dave Tweed Oct 17 '12 at 15:26
  • 2
    \$\begingroup\$ This is a software development question, and there are many questions on SO, for example: stackoverflow.com/questions/984866/why-use-c \$\endgroup\$ – Ben Voigt Oct 17 '12 at 18:24
10
\$\begingroup\$

The correct question is not "C or C++" (with a one-bit binary answer) but "which C++ features to add to my C (and which C features to discard as a consequence)" (which has a whole lot of bits, which will probably vary with the particular project and chip).

There are some C++ features that you should defintely use because they correct 'mistakes' in C, and have no code or run-time overhead, like:

  • bool type with true and false values (C has no single 'true' value)
  • passing parameters by reference (instead of by pointer)
  • using new/delete instead of malloc/free
  • for( int i = 0; i < n; i++ )
  • declare a variable immediately before the (first) statement that uses it
  • local arrays that have a calculated size

Note that some of these features are making it into the newer C versions.

Some other features should probably be avoided on microcontrollers because they have a (sometimes big) overhead:

  • run-time type information (RTTI)
  • exceptions (IMO they jury is still out on this one)
  • std::cout with its wonderfull << operators (this is not a language but a library issue)

Other features can be a big advantage, but will take some time to learn and apply properly, like

  • classes
  • inheritance
  • virtual functions
  • templates

So, to summarize: if you have the chance to use a C++ compiler by all means use it, and start using C++ features one by one as you find good use for them. Don't feel obliged to swallow all of C++ in one go.

\$\endgroup\$
  • \$\begingroup\$ Good answer, but I'm curious about why you think the fact that "C has no single 'true' value" is a 'mistake'. \$\endgroup\$ – Dave Tweed Oct 17 '12 at 15:31
  • \$\begingroup\$ Note the ''s. It is a problem in the current C language that there is no single 'true' value in the sense that you can write "if( TRUE == f())...". Whether it is a true mistake (in the sense that "K&R should have known better") is not very relevant. It is a problem, and C++ has a solution. \$\endgroup\$ – Wouter van Ooijen Oct 17 '12 at 15:40
  • \$\begingroup\$ Do serious programmers really write code like that? How do you test the value of the expression TRUE==f()? Wait, I know: if(TRUE==(TRUE==f())) ... Hmm. I think I see a problem here... :-) \$\endgroup\$ – Dave Tweed Oct 17 '12 at 15:58
  • 1
    \$\begingroup\$ Maybe the current C lore has improved enough, but when I was doing C the lore was that a 'boolean' function could return any non-0 value to represent true. Is that no longer the custom? In that case most of my problem would vanish. \$\endgroup\$ – Wouter van Ooijen Oct 17 '12 at 17:10
  • 1
    \$\begingroup\$ @m.Alin Even better, if you have a compiler with decent C++11 support (likely if you are using a variant of GCC), you can use the new range-based for loop: for(int &x : array) \$\endgroup\$ – Suboptimus Oct 17 '12 at 18:55
2
\$\begingroup\$

In general C allows you to write code that compiles into a smaller/faster binary than C++.

C++ is a super-set of C. It gives you the powerful features of object oriented programming, which allows better reuse/scaling/etc. and becomes more important as the size and complexity of your software solution grows. This comes at the cost of higher overhead, both in the size of the generated binary, in the amount of required memory (RAM) for execution and in speed of execution.

Microcontrollers (uCs) usually run slower than full size microprocessor, and have limited code storage and execution memory. All of this makes C more suited for programming uCs. You will also find that most drivers/libraries/existing code for uCs (provided by vendors and community) are written in C. Although C libraries can be used in C++ programs, if you want to contribute back to the community, C is preferred for uCs.

\$\endgroup\$
  • 2
    \$\begingroup\$ With suitable compiler settings (no RTTI, no exceptions) a C++ compiler should generate almost the same binary as a C compiler (OK, it needs to cycle trough the global constructors). \$\endgroup\$ – Wouter van Ooijen Oct 17 '12 at 17:11
  • 1
    \$\begingroup\$ @wouter good comment, there are strategies which do not use constructors, on the other hand expressing things in the form of templates often removes more dead code than c can. In other words c++ can be much faster and smaller. \$\endgroup\$ – odinthenerd May 12 '15 at 11:07
1
\$\begingroup\$

Well, all you need is in C. Any C++ code uses standard C to accomplish tasks on microcontrollers. C++ might help you write "nicer", portable code, with classes and methods if you want to promote your work to hobbyists (See Arduino project), at the cost of greater overhead. But the embedded systems industry has survived this long on C, it just depends on your requirements. The AVR-GCC project has aliases for all registers and bits named in the datasheet, so the code is pretty readable.

\$\endgroup\$
  • 1
    \$\begingroup\$ Any c Code uses assembler, shouldn't we just use assembler then? No! It's all about static checking and optimization, in both cases adding C++ functionality can be better. \$\endgroup\$ – odinthenerd May 12 '15 at 11:01
1
\$\begingroup\$

...and if I may add, from perspective of primarily electronics hobbyist vs programming, fewer lines of code not only saves precious/limited memory space on uC but requires less current overhead,battery requirments(capacity, weight, size) and generates less heat...the latter can cause chip performance problems. All the above vital if we are to use thin, light smartphones which are to reliably provide many functions and services. Thus, software issues and hardware needs/limitations are linked. Humbly submitted.....

\$\endgroup\$
  • 1
    \$\begingroup\$ Lines of code is a rough measure of complexity but when comparing two different languages lines of code is a terrible way to measure how the code will compile. As someone whom has done both C and C++ I do not think your post gets to the root of this. Sorry to disagree with your first post, but I thought it might help you to know this also. \$\endgroup\$ – Kortuk Oct 18 '12 at 14:02
  • \$\begingroup\$ Lines of code means little with a good optimiser. \$\endgroup\$ – odinthenerd May 12 '15 at 11:08

protected by Kortuk Oct 18 '12 at 14:03

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.