reasons for preferring C over C++

I'll have him go through it, but I have the impression that the author was only half-serious when he wrote most of the items. Which of course makes it into a fun reading.

Wouter

Depending on the resources available (on the die), you might not even get a "full" C for some devices. Especially legacy devices that predated the HLL craze (in MPU/MCU's).

IME, this is the primary advantage of C over C++ (but, then again, I primarily write RT code)

I consider this a *weakness* of C! If you are "forced" to make a cast, you should be thinking a bit more about what you are doing and why the cast is necessary (it may be -- I'm just commenting that C's "tolerance" on this often leads to errors that stronger type checking would have caught). Too often, I see (desktop) apps that "need casts" but the (C) compiler warnings are ignored. On closer inspection, often some of these warnings point out flaws in the code!

Yes and no. A lot of that depends on coding style.

You could consider the number (and *types*!) of "programmers" fluent in each. That can influence your decision. In small shops, you may *need* a "hardware guy" to develop your hardware. He may end up also being tasked with writing the firmware.

Or, you may have software types, exclusively, who just purchase COTS boards and modules and just build an application on some "BSP", not caring about the hardware.

Consider, also, the guys who will be coming AFTER the initial development ("maintenance").

You can also look at library support (if a third party library is/isn't available in a binding to your language of choice).

Also, how robust the "components" on which you are building your application (C++ does a better job, in general, at information hiding -- which can be good, or bad!)

C++ solutions (IME) *tend* to rely on memory allocation far more heavily (and less "obviously"). E.g., a C implementation shows all allocations essentially explicitly. C++ allows anonymous/transitional objects which appear "between the lines" of your codebase. If memory is tight (small processor), youo may not realize these allocations/releases are happening until your code crashes.

[In C, you have to explicitly perform them -- aside from auto vars, etc. -- so you are much more aware of them]

I think that the best service you could offer the student is to tell how some C++ functionality is implemented in C/assembly.

+42!

This would be a great "exercise"!

Conversely, how C++ can "abbreviate" (syntactically) common sequences of operations that one might carry out in C (and why this is A Good Thing or A Bad Thing)

snipped-for-privacy@downunder.com schreef op 15-Oct-14 8:03 PM:

He is reasonably aware of that. What is is to search for is reasons people *cite* for preferring C over C++, so his own opinion is (at this stage) not the point.

Wouter

That would be the killer argument for me. There is no point in reasoning about using C++ if all you have for your chip is a C compiler. (And there is no point in reasoning about using C if all you have is an assembler and a crappy gcc 1.x.)

You can work as close or as far from the machine as you want. It just takes much more experience in C++ than in C to know what language constructs cost you what in terms of code and memory. I have written boot loaders in C++ ("boot loader" as in "configure RAM and flash and then get that image running ASAP", not "fancy shell prompt with menus and file system and stuff over serial and TCP").

C's advantage here is that it's a WYSIWYG language: if you want bloated code, you actually have to write it. In C++, you may get the bloat by accident if you're not careful. On the other hand, you can write hundreds of lines of code with dozens of (template) classes that don't generate a single machine instruction.

A concrete instance of this problem is that it's easier to avoid needing libraries in C. About the worst function call a C compiler will generate implicitly is memcpy, memset, or things like long multiply. If you write C++ as it's meant to be, with destructors and all, you'll easily get functions into your code (exception handling) that you cannot simply replace by a three-line *.asm file.

The only cast you need in C++ that you don't need in C is the void*->something* cast. And you need fewer void*->something* conversions in C++ than in C if you translate the "callback + void* pointer" idiom into a "class with a virtual method".

The thing that gets bazillions of casts into your code is MISRA, not C++ :-)

This applies to C as well. If you start using it (and you should), you have to use it everywhere.

Some C++ error messages are hard to decipher, but compilers are getting better.

Stefan

I'd split that into two reasons, as they are very different issues.

(Before anyone replies here, remember what Wouter asked for - reasons without regard to validity! Some of these here are commonly-believed FUD.)

How about:

C lets you write spaghetti code which is hard to understand, C++ lets you write lasagne code which is even worse.

Exceptions are just undocumented gotos.

All other embedded code, such as RTOS's or network stacks, is written in C - so you can't work in pure C++.

Templates cause code bloat.

The STL causes code bloat.

Objects in C++ use the heap, and dynamic memory on a small system is bad.

Objects means everything involves at least one pointer (*this), which is inefficient on small cpus.

Templates make code unreadable and undebuggable.

You can't use advanced C features, such as VLA's and designated initialisers, in C++.

Coding standards insist on ANSI C.

Some quotations from Bjarne Stroustrup might help too () :

Within C++, there is a much smaller and cleaner language struggling to get out.

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.

Fun reading, /and/ doesn't affect the validity.

Something similar could be done for C, of course.

What I meant that (in my impression at least) being only half-serious enabled the author to be much more funny than he could have been if he was fully serious.

Wouter

IIRC the author of that was referring to run-time problems rather than compiler errors.

Wouter

True. I lumped them together because the both have nothing to do with the language itself. Availablility of libraries (other than the standrad libraries) could be added here.

I think you fully understand what I am asking for! Although some of your quotes fall under "purely emotionally rants", they still represent reasons for some persons not to use C++. I strust my student will have plenty of material.

Wouter

There's an English expression that has been around since

1390: "many a truth is spoken in jest". The interesting question is how many of the author's observations and statements are valid.

From my point of view, the answer is "too many". But then I've long been of the opinion that "if C++ is the answer, then what was the question?" - and can we 'revisit' the question

C++ vs C is such a flame war because C++ really does solve some of C's problems, but on the other hand it introduces its own problems, so there are partisans on both sides. Stepping back, both are terrible, and the only reason to use C is the highly mature toolchains, availability of programmers, existing API's that expect it, and tons of legacy code.

Unfortunately it's hard to see good alternatives that got any traction.

It takes more knowledge of C++ to write really small code for it. It still takes knowledge of C to do the same thing, but C comes with less to begin with, and it's more obvious when you use it.

C++ really starts to shine as applications get big. So even if you can use it in a really small application, you're not going to use its features to great advantage. This isn't really a fault of C++, but it certainly is a lack of advantage.

--
www.wescottdesign.com

There are exceptionally good responses.

I'd like to add that a serious programmer for small chips must read and understand the generated assembly code, to avoid nasty surprises. (I've had enough of them during 50 years of coding ...)

--

Tauno Voipio

For one perspective, have a look at the book "Real-Time C++: Efficient Object-Oriented and Template Microcontroller Programming" by Christopher Kormanyos. For most of the book he uses an AVR.

The biggest hurdles to using C++ are in my opinion poor compiler support and the fact that it is just a vastly more complex language than C. It is also still rapidly evolving, and the things you learned ten years ago might just not be valid anymore.

-a

Very true.

I've recently been horrified about the proportion of "programmers" that haven't got a clue about the basic relationships between what's source code and what's in the corresponding machine code. By "basic" I mean giving some /pseudocode/ for a function call with arguments.

If that is a problem, it is a consequence of the semantic distance to the machine, as you put it: if a single line of code can generate a few hundred machine instructions, have a lot of fun debugging what exactly caused the program to generate a SIGSEGV in the middle of that.

Other than that, if you've made a mess of pointers and structs in C that won't be a bit easier to debug than if you've made a mess of pointers and classes in C++.

Stefan