Programming in C++, Rules and Recommendations |
|||
|
ISBN : - |
Order a printed copy of this book from Amazon --UNAVAILABLE-- |
||
![]() Cover Design - Programming in C++, Rules and Recommendations |
For your free electronic copy of this book please verify the numbers below. (We need to do this to make sure you're a person and not a malicious script) | ||
|
Sample Chapter From Programming in C++, Rules and Recommendations Copyright © FN/Mats Henricson and Erik Nyquist |
|||
1 IntroductionThe
purpose of this document is to define one style of programming in C++.
The rules and recommendations presented here are not final, but should
serve as a basis for continued work with C++. This collection of rules
should be seen as a dynamic document; suggestions for improvements are
encouraged. A form for requesting new rules or changes to rules has
been included as an appendix to this document. Suggestions can also be
made via e-mail to one of the following addresses: erik.nyquist@eua.ericsson.se
Programs that are developed according to these rules and recommendations should be:
Questions of design, such as how to design a class or a class hierarchy, are beyond the scope of this document. Recommended books on these subjects are indicated in the chapter entitled "References". In order to obtain insight into how to effectively deal with the most difficult aspects of C++, the examples of code which are provided should be carefully studied. C++ is a difficult language in which there may be a very fine line between a feature and a bug. This places a large responsibility upon the programmer. In the same way as for C, C++ allows a programmer to write compact and, in some sense, unreadable code. Code written in bold type is
meant to serve as a warning. The examples often include class
definitions having the format "class Many different C++ implementations are in use today. Most are based on the C++ Language System by AT&T. The component of this product which translates C++ code to C is called Cfront. The different versions of Cfront (2.0, 2.1 & 3.0 are currently in use) are referred to in order to point out the differences between different implementations. Rule 0 Every time a rule is broken, this must be clearly documented.
|
|||