Trampas Stern,
I'm sorry, but I've got to chime in here grasshopper. David Kelly put
it well: just "don't use C++"!
I somehow knew that this would start a flame war. :-)
[FLAME ON] We've been there, done that, bought the T-shirt, here in
forums like this before, going back many decades! I've heard all your
silly platitudes repeatedly here and in other places---always coming
from "wise fools" like yourself.
IMNSHO putting your specious arguments "on the Internet" for all
posterity to see is not the best move professionally. When I see
statements like yours:
/"Note that I have worked on projects in the past where we squeezed
every clock and every byte out of a processor. However I have not had to
optimize for size or speed in 10 years. That is processors are so cheap
and powerful if you have to optimize code for size or speed then you
most likely picked the wrong microprocessor."
/
...you are definitely NOT ever going to be working with me.
Why is plain old C still one of the most popular programming
languages---number 1 by some measures (i.e.,
https://tiobe.com/tiobe-index/)? It's because commercial embedded
systems ALWAYS directly benefit from small and fast. If you are a
hobbyist you can make statements like you did. However us professional C
programmers that get paid the "big bucks" are in demand precisely
because they can deliver products that run with minimal compute
resources on the least expensive microcontrollers possible!
And, yes one can reuse C code---I've been doing it for decades. As for
interrupt handlers and device drivers, between C macros and
programmatically generated C code (e.g., Perl scripts) you can have it
all without the "crutch" of C++ templates and class nonsense. [FLAME OFF!]
BTW: I suggest that you quit while you're ahead---but David and I
somehow know that you won't! :-)
Best regards,
Bruce D. Lightner
Lightner Engineering
La Jolla, California
light...@lightner.net
https://www.linkedin.com/in/brucedlightner/
------------------------------------------------------------------------
On 4/10/2021 3:36 PM, 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.
I find that in most of my embedded projects the cost of development
time is more than the cost of the processor for 5 years of production,
that is the products are not super high volume products. As such,
reducing development time is very important. To this end I do things
like write libraries and test them, and then reuse them. For example
I write an abstract interface class for a CharDevice, and BlockDevice.
Then a UART can be a CharDevice and EEPROM a BlockDevice, SDCard is a
BlockDevice, etc. This allows faster development. Sure I can do this
in C, but C++ basically does the same thing I would do in C and is
easier to understand.
Also things like templates are valuable, for example I wrote a FIFO
template. I debug that template once and never have to write fifo
code again. This is something very hard to do in C with any
efficiency. Now I can create a FIFO for uint8_t, uint32_t, or a
structure with one line. This can not be done easy in C. The same is
true for circular buffers and such...
So yea C++ on embedded is very valid and real. I have been doing
professional embedded C for over 30 years and just switched to C++ and
do not want to go back to C. The misconceptions about bloat are no
longer valid. Sure you can write bad C++ code using standard
templates and such but you can also write bad C code, so don't do
either. I think the misconception about C++ is because people try to
do stupid stuff like use cout, new, RTTI, exceptions, etc. Where most
of the time the simple compile time features of C++ offer huge
advantages over C.
At the end of the day all the compile time features of C++ are
free, like classes. There is zero reason not to use them because they
are free. The run time features are not free but you can choose what
you use, and turn off what you don't need.
So yes I can write bad C++ code that is slow and bloated. I can write
bad C code that is slow and bloated. My job is to write functional
code that works and works correctly with no side effects and I can do
that faster and more efficiently in C++ using OO and minimal features
of C++. Maybe others can not, but that is not my problem.
Note that I have worked on projects in the past where we squeezed
every clock and every byte out of a processor. However I have not had
to optimize for size or speed in 10 years. That is processors are so
cheap and powerful if you have to optimize code for size or speed then
you most likely picked the wrong microprocessor.
The problem with interrupt handlers which I asked about still exists
if you use C to write the code. That is you still have to map the
interrupt handler to the correct instance of the object unless you are
insane and write a driver for each UART instance, which talking about
bloat and slow....
Trampas
On Sat, Apr 10, 2021 at 5:12 PM David Kelly <dke...@hiwaay.net
<mailto:dke...@hiwaay.net>> wrote:
On Apr 10, 2021, at 2:37 PM, Trampas Stern <tst...@nc.rr.com
<mailto:tst...@nc.rr.com>> wrote:
If you guys have a better way I would love to know.
Don’t use C++?
What does object-oriented coding do for embedded projects? It’s
akin to using printf(). Slow and lots of bloat.
Time once was I put uint32 in a union so as to code ++ inline
rather than let avr-gcc call a library routine. Even more so if in
an interrupt. Not all library routines used to be re-entrant.
--
David Kelly N4HHE, dke...@hiwaay.net <mailto:dke...@hiwaay.net>
============================================================
Whom computers would destroy, they must first drive mad.
/CONFIDENTIALITY NOTICE: This e-mail and any attachments may contain
confidential information intended solely for the use of the addressee.
If the reader of this message is not the intended recipient, any
distribution, copying, or use of this e-mail or its attachments is
prohibited. If you received this message in error, please notify the
sender immediately by e-mail and delete this message and any copies.
Thank you./