"The man who grasps principles can successfully handle his own methods. The man who tries methods, ignoring principles, is sure to have trouble." -Ralph Waldo Emerson
When you understand your requirements, processor, and tools (compiler) then you can pick the best method to optimize for desired results. Blanket statements like "Don't use C++" or that is "Slow and lots of bloat." might be true based on how you would use the tools.
I agree C is a great programming language, it does has problems and every year I learn new things I did not know in C. I also learned C++ and was in the camp of no embedded C++ ever. Then I did some testing and read more, for example:
I found that C++ was not evil if you knew how to use it. So I started doing some tests and found that in many cases the higher level abstraction was worth it on larger projects. Plus I learned what was free in C++ and what caused bloat and slowness.
For example here is the lines of code count for one of my last embedded projects:
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C/C++ Header 246 20651 33660 89579
C++ 51 3977 3362 36695
C 20 3545 6605 12705
DOS Batch 1 0 0 2
-------------------------------------------------------------------------------
SUM: 318 28173 43627 138981
-------------------------------------------------------------------------------
The code is large enough where the abstraction that C++ provides helps us manage the project better. This may have resulting performance and code size hits on the processor, but it is worth it for the benefits.
Trampas