ljknews wrote: >> And there are ways of using Assembly Language to avoid pitfalls that it provides. There are ways of using horse-drawn carriages to avoid the major reason (think street cleaning) why the automobile was embraced in urban areas during the early part of the 20th century.
What there are _not_ are reasons for new development to cling to languages which make flawed constructs easy for the individual programmer to misuse. << There is often one very good reason for clinging to such languages: because there is no other suitable language available. As has already been pointed out, there is usually very little alternative to C/C++ when it comes to kernel mode code. I would love to see a safer alternative to C/C++ for writing operating system kernels, device drivers and real-time embedded applications (yes, I know Ada can be used for the latter, buts its package structure and associated "with-ing" problem can be a real pain in large systems). The newer programming languages such as Java, C# and Eiffel are all designed for applications and make heavy use of garbage collection (which is a boon to application writers, but a no-no for kernel code and many embedded apps). What I don't understand is why the language standardisation committees don't remove some of the unsafe dross when they bring out new language revisions. A classic example is the failure to define the type of a string literal in C as "const char*". Just imagine if we had a new version of C++ with all the unsafe stuff removed. Backwards compatibility would not be a problem in practice, because the compiler suppliers would provide switches to make their new compilers accept obsolete constructs. As for non-real-time application-level code, I gave up writing them in C++ by hand long ago. [Actually I prefer to write specifications, verify them, and let a code generator produce correct C++ from them; but that is another story.] David Crocker Consultancy & contracting for dependable software development www.eschertech.com