Richard said:
That's what I said. No properly written malloc() calls, for starters.
Which may be a small price to pay.
Just to put a few things in perspective, let me describe a real life
situation where compiling an embedded C application with a C++ compiler
on the development platform (note: *not* on the target) helped the
development process.
There were three main reasons, firstly I wanted to test device drivers
down to simulated device level. To do this I provided two definitions
of the device registers, in C a struct of bit fields and in C++ a struct
of structs where each bit was a member function, so setting a bit caused
the simulation to react as the real device would.
Second, the test rig had to work with misaligned data (sent to and from
a target system) the host compiler did not support, so again in C the
packets were represented as structs of POD and in C++ as structs of
structs that packed and unpacked the data.
Third, we wanted the extra static type safety offered by C++. We made
heavy use of enums as function parameters and the stricter conversion
rules prevented inappropriate types being passed.
This may be a specialised case, but I have used the same techniques for
many years in the development and testing of embedded systems.
None of this host based testing is a substitute for rigorous acceptance
testing of the target system, built with the target C compiler, it
merely augments it and helps with the development.