"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: https://www.embedded.com/modern-c-in-embedded-systems-part-1-myth-and-reality/ https://bitvolatile.com/?p=326 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 On Sat, Apr 10, 2021 at 11:40 PM Anton Staaf <an...@socialhacker.com> wrote: > For those that care, and ignoring the flame war, I believe that your > (Klaus) problem likely stems from the following GCC bug: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70435 > > Sadly, support for C++ in AVR GCC is not a priority, so I wouldn't expect > it to be fixed. I've been able to work around this myself using explicit > template instantiation, because I'm relying on a slightly different > attribute that isn't propgated correctly. I'm tagging an object as living > in the .vectors section, and making its memory layout match the vector > table layout for AVR processors. This lets me generate only the vectors > that are required using template meta programming based on the interrupts > that are listened for. I've built my avr-gcc with "--with-avrlibc=no" and > "--without-newlib" to suppress the misspelled ISR warning. > > -Anton > > On Sat, Apr 10, 2021 at 8:19 PM Russell Shaw <rjs...@netspace.net.au> > wrote: > >> On 11/4/21 8:36 am, Trampas Stern wrote: >> > Actually C++ is not slower or more bloat than C, depending on the >> features used. >> > >> > For example I do not use RTTI or exceptions, so that makes it about the >> same as >> > C for size. Yes you have to turn these features off in your compiler >> (-fno-rtti, >> > -fno-exceptions). Sure you have trampolines or jump tables for >> function >> > overloading but you have to do the same in C. If you do not use >> inheritance or >> > function overloading you do not have the penalty. >> >> Function overloading is a compile-time concept, but the result after name >> scope >> flattening are simple function names that are called without any extra >> pointer >> indirections (ie, no different than C). >> >> C++ is as efficient as C only if what is written translates to the >> equivalent >> form. This is easy to do, but only after a large hurdle of understanding >> how C++ >> compilers work. >> >> The biggest shortcoming in the C++ "industry" is that there is no >> literature i >> have seen that explains in a compact way how you can look at a piece of >> C++ code >> and see how it would translate to the equivalent assembly, which is the >> main >> advantage of C. >> >>
