Well, an object-oriented approach affects how information is mapped to storage. Heavy reliance on indirect access is not efficient unless you have several pointer registers that can directly address reasonable areas of memory.
My actual point (not well stated I agree) is that you can write C in C++. You don't have to use the bells and whistles.
For boolean data, forcing all of each object's attributes into a single memory block wastes space and code compared to using a bitstring for each attribute, indexed by object number, which AFAIK you can't do in C++. Unless you want to violate the object oriented principles.
If you can do it in C you can do it in C++. If you're arguing that C++ doesn't implement objects in the best way possible, I'm not going to argue with you. C++ has lots of evidence of being bolted on to C (which is because this is exactly what happened).
"C is combines the elegance and power of assembly language with the readability and maintainability of... assembly language".
Back in 1982 that was probably true, but modern compilers and architectures (NOT small MCUs!) can be extremely efficient; often better than run-of-the-mill-quality assembly language.
This tends to be an argument for C over assembly language, and, if anything, makes the use of C++ features less of an issue (indeed it makes them possible). Unfortunately it has done nothing for the readability of C/C++.
Objects are passed by reference. Whether the reference is (internally) a pointer or not, eventually, objects have to be accessed through pointers. The AVR, and especially the smaller PICs, are horribly inefficient at pointer indirection.
And so you write code in a way that doesn't require pointer usage as far as possible. Globally (or at least statically) defined variables (of whatever type) that are accessed directly rather than via a pointer passed as a parameter will overcome most of that overhead.
The baseline and mid-range devices (excluding the "enhanced" mid-range devices) have only one static pointer register, and messiness quickly multiplies if you want to use it in an interrupt handler. IMO, these small devices aren't even C-friendly; to C++, they're positively hostile! Larger devices are a different story though.
I wouldn't argue against that much either. Even though most modern optimizing compilers can write generally better assembler than a normal person, they cant always do that, nor can they beat all humans. In a small device, the task is likely to be similarly small, and the optimizer will have less opportunity and the human probably more. The point, however, is C vs C++.
Many library calls are inefficient for small MCUs too, in any language, because many of them have to use pointers to remain generic.
A lot depends on the compiler. If the function is a method of a statically declared object, the compiler *may* be able to inline the call completely and not require any pointers at all (and the same may be true of other non-object function calls). Of course, unless you look you'll never know.
In general, if the code does all of the following:
- works
- Is fast enough
- fits
Then your job is done. Personally, I would prefer to make it work better, run faster, and fit in a smaller memory footprint. Unless there are economic imperatives, that may not happen. It's even less likely to happen if (any of the following):
- you're a beginner
- bigger/faster device is cheaper
- the quantity is small.
When we get a question like:
I love programming uControllers and for the most part I use C. The other day while chatting with a friend he asked me if I program in C or C++. Now I have to admit I didn't know the difference between the two. I did some research and from what I found C in a top-down approach and is function driven while C++ is object driven.
...it demonstrated a fundamental misunderstanding about programming and/or about the differences between C and C++.
The difference between C and C++ is that C++ has a few more bells and whistles that makes certain programming paradigms easier than they would be in C.
"Top down approaches" vs "object driven" are design methodologies more than anything else.
As a general rule, top down and bottom up are both employed. The control and big picture stuff are generally top-down. Interfaces are generally bottom up. Data falls between the two. The language doesn't (or shouldn't) change that.
I will only be using C to program uControllers, that's it. Which is the better option for me, should I teach myself C++?
You should at least be familiar with C++ because you may need to understand code written in C++. An example you google may not be in plain C.
