Victor Bazarov wrote:
"Matt Priest" <ml******@micro n.com> wrote...
I am trying to learn more about how to effectively mix low-level C code
with C++. I am having trouble finding resources/papers/books that
aren't in one or the other camp exclusively.
Shouldn't that serve as a hint for you?
Can anyone point me toward a good place to start?
You should probably start with a decent C++ book.
I want to understand
how to make decisions about the development environment, code structure
and planning, and any other issues that I'm not aware of that may be
important to know.
This has nothing to do with either language. Visit comp.software-eng.
Victor's comment is 100% right but that is not the perception I hear
from embedded and low level engineers.
There are 2 factors that confound the issue for C++. The first is
complexity. C++ is far more complex than C and while the run-time
implications of C++ are miniscule and often far more favorable than C,
however the "programmer insecurity" factor kicks in and most engineers
don't leave themselves the time luxury to learn C++. The second factor
is the STL. The STL has some very cool features, however it is not
effective for the embedded paradigm where space and resource utilization
is a major issue. In some cases, real-time (also regulatory) contraints
preclude the use of the STL.
Every discussion I have had with an anti-C++ embedded programmer, I have
been able to give constructive discussion about how moderm compilers and
C++ have an excellent synergy and got them thinking about the
possibilities (or I just bored them to submission, I have yet to find out).
There are a couple of meanings to "low level" - 1. kernel and driver
code and 2. embedded code. The constraints are very similar.
Performance and resource utilization constraints are more significant
that application code. Also, most low level code needs to run for much
longer periods and the consequences of code failure is far more
significant. (e.g. my cell phone crashes ... it's true ...).
Significant factors for embedded apps:
1. code size (limited ROM space)
2. stability (*must* never crash)
3. real-time (if a coms interrupt is not serviced, data is lost)
These are more design issues than language issues. However C++ does
have some very nice tools to be able to achieve these 3 that C does not.
C++ templates allow you to create very efficient "policy" objects that
allow you to create very stable and much easier to maintain code.
Inlining small methods increses performance and may actually reduce code
size.
OK - I'm done with the ranting ... for now.
