A frequently overlooked source of good material on high integrity software development is the Federal Aviation Administration's Air Software site.
For example right now you can get a free CD from them, while they last. Always nice to see that our taxes do, on a rare occasion, produce something that can be used:
"Presentations from the 2009 Software & Airborne Electronic Hardware (SW&AEH) Conference are still available on CD. To request a CD, send [the FAA] an email with your name and mailing address."
The item worth pointing out the most, on the Air Software site, is:
Object Oriented Technology in Aviation (OOTiA) Handbook, Published October 26, 2004.
- Volume 1 (PDF) - Handbook Overview
- Volume 2 (PDF) - Considerations and Issues
- Volume 3 (PDF) - Best Practices
- Volume 4 (PDF) - Certification Practices
The languages C++, Ada95 and Java are covered. However what is more important is the introductory material and reasoning behind Object Oriented Technology. This is Must Read material for someone pondering switching from C to C++.
The OOTiA is also an excellent introduction to proper software development mentods.
The Handbook does make the common error of confusing Concurrency with Simultaneity, giving the errant definition of: "Concurrency is the process of carrying out several events simultaneously."
'Concurrently' in the context of Embedded Systems means "Apparently at the same time", while 'Simultaneously' means "At the same time". The distinction is subtle but extremal important to creating correct real time code. A small single core Micro will never be executing different instructions simultaneously, yet it will be doing many things in hardware such as ticking timers and receiving characters via a serial port simultaneously.
Just because we might be able to use Object Oriented Methodologies in our systems, does that mean that we should? Volume Two of the OOTiA addresses this, as do a couple of articles from Embedded Systems magazine: Nuts to OOP and Michael Barr's rebuttal.
"Adoption of C++ does not suddenly transform C programmers into object-oriented programmers. A complete change of thinking is required, and C++ actually makes this difficult. Many of C’s problems affect the way that object-orientation is implemented and used in C++."
"Going object-oriented for the wrong reasons: There are "many more misunderstood, misguided, or just downright bad reasons for going object-oriented". These include (but are not limited to): wanting to cut back on development staff, thinking OOT will significantly reduce the need for testing, thinking that your project can be completed five to ten times faster using OOT, thinking the use of OOT will reduce project risk, and wanting to be able to build future products simply by plugging software components together."
Volume Two also covers one of my pet-peeves Identifying Dead and Deactivated Code. Volume Three gives details issue of dead object code. Seeing lines of dead source code, code commented out with "//" in C code, irritates me to no end. What is worse is there is no comment as to why the code was commented out, then left in the source file. If you do really need to comment out code use "#if 0 #endif when working in C.
There are two standards that try to illuminate some of the darker corners of C++, to make the language safe to use in Embedded Systems, MISRA C++ and Joint Strike Fighter Air Vehicle C++ Coding Standards. The fact that we have to have such standards implies that we are using the wrong tool for the job. The question becomes is there a safe tool, ie: language for hard real time systems? Erlang comes to mind for soft real time systems.
In looking around I did stumble across a 'safe' version of C# called Spec# from Microsoft Research. Alas it looks like a dead project, and the likely hood of it working on a small micro is zero.