From: pcm@scammell.ecos.tne.oz.au (Peter Murray)Newsgroups: comp.lang.c++.moderatedSubject: Evil C++ Techniques: A ListingDate: 26 Mar 1996 09:16:21 -0000I need feedback...As part of a C++ style guide for my group I am putting together a list of things you can do in C++ but *really* shouldn't.  I would appreciate any comments, criticisms, additions to the list, additional references, etc...  Where there is a reference(s) available I don't provide any detailed descriptions.  I leave it to the reader to to investigate the reasoning behind each point in the listed references (this is meant to be a relatively *short* guide).Thanks,- Peter---------------------------------------------------------------------Contents:(a) Techniques to Avoid(b) Outdated/Superseded Language Constructs(c) References------------------------------------------------------------------------------------------------------------------------------------------(a) Techniques to Avoid---------------------------------------------------------------------1)   Never redefine an inherited nonvirtual function.  In derived      classes, only redefine the virtual functions of the base class.  Exceptions: None  Ref: [2] Item 372)   Never redefine default parameter values defined in virtual base     class functions.  Exceptions: None  Ref: [2] Item 38       [8] FAQ 1443)   Never overload &&, ||, or ,(comma operator)  Exceptions: None  Ref: [3] Item 74)   Avoid the use of interface specifications.  Exceptions: Rarely  Ref: [4] p.76       [10] Section 9.6, p.3175)   Always define at least one constructor.  Exceptions: None  Ref: [4] p.11       [3] Item 46)   Do not allow the compiler to generate a default destructor.  For     each class, always define a destructor.  Exceptions: None  Ref: [4] p.11       [8] FAQ 1967)   Avoid using the compiler generated assignment operator.   Exceptions: If you don't dynamically allocate any data (e.g. via new)               on the heap you don't need to declare an assignment               operator.  If you want to use the compiler generated              assignment operator insert a commented declaration to               show that this is your intention;               // TObject& operator=(const TObject&);  // Use default.  Ref: [4] p.11       [8] FAQ 198       [2] Item 118)   Avoid using the compiler generate copy constructor.    Exceptions: Same as for compiler generated assignment operator.  If               you don't dynamically allocate any memory you may be safe              with the compiler generated version.  If you want to use               the compiler generated copy constructor insert a              commented declaration to show that this is your               intention;               // TObject(const TObject&) ;  // Use default.  Ref: [4] p.11       [8] FAQ 1979)   Avoid member assignment within the constructor.  Use member      initialisation lists with constructors rather than assignment      inside the constructors.   Note that initialisation list members      should be listed in the same order as they are declared in the      class definition.  Exceptions: When you have a large number of data members of built-in              types, that are initialised the same way in each               constructor, in which case you would use a common               initialisation routine.   Ref: [2] Item 12       [2] Item 13       [8] FAQ 133       [8] FAQ 188       [8] FAQ 19110)  Public member functions should not return references or pointers      to protected or private members.  Exceptions: For performance reasons it is sometimes acceptable to              return a reference or pointer to a const object.  Ref: [2] Item 30       [2] Item 2111)  Data members must not be public.  Exceptions: None  Ref: [2] Item 2012)  Never return a reference or pointer to a local object.  Exceptions: None  Ref: [2] Item 23       [2] Item 3113)  Do not ignore compiler warnings.  Exceptions: Rarely  Ref: [2] Item 48     14)  Never hide a public member function of a publicly derived base      class.  Exceptions: None  Ref: [8] FAQ 12215)  Do not use Hungarian Notation. Due to the intellectual inertia      of C programmers moving to C++, it may pay to list some of the      problems with Hungarian Notation when applied to C++;      - Ignores the use of abstract data types as base types.      - Forces programmers to worry about manual type checking         instead of letting the C++ compiler check the types more         rapidly and accuratley.      - Combines purpose with type.  If you change a variable's type         you should not have to change its name throughout the         program.  Variables can quickly become out-of-date when their         type changes but their name is not changed (through laziness         or mistakes or overlooked).      - Encourages lazy, uninformative variable names.      - With C++ there is no need to know the exact representation of         a variable in order to manipulate it.      - No need in a strongly typed language such as C++.  Hungarian         Notation was designed for weakly typed languages such as C.      - Does not mix well with polymorphism.      For an alternative naming convention, see [4] p.33  Exceptions: When programming at a low-level in a C-like manner (or               using embedded assembly code) and interfacing with               hardware that requires the programmer to know the exact               representation of a variable or data structure in order               to manipulate it.  Such code should probably reside in              seperate C specific modules.  Ref:  [5] p.206        [4] p.33---------------------------------------------------------------------(b) Outdated/Superseded Language Constructs---------------------------------------------------------------------1)    #define values      Alt:  const values.      Ref:  [2], Item 1            [8], FAQ 3322)    #define macros      Alt:  inline functions or templates.      Ref:  [2] Item 1            [2] Item 33            [8] FAQ 3493)    malloc      Alt:  new      Ref:  [2] Item 3            [8] FAQ 301      4)    free      Alt:  delete      Ref:  [2] Item 35)    stdio.h      Alt:  iostream.h      Ref:  [2] Item 2            [8] FAQ 3736)    printf      Alt:  operator<<      Ref:  [2] Item 27)    scanf      Alt:  operator>>      Ref:  [2] Item 28)    /* ... */  (C-style comments)      Alt:  //   (C++ style comments)      Ref:  [2] Item 410)   raw C pointers      Alt:  STL auto_ptr      Ref: 11)   raw C char strings      Alt:  STL string      Ref: 12)   raw C casts      Alt:  static_cast            const_cast            dynamic_cast            reinterpret_cast      Ref:  [3] Item 213)   unspecified arguments e.g. printf (char*, ...)      Alt:  default arguments or function overloading      Ref:  [4] p.4514)   Error return codes      Alt:  exceptions             (I'm not sure about this.  Exceptions can be real buggers to            work with.)             (How does exception handling affect size/performance?)      Ref:  [8], FAQ 24415)   Local variables declared at the top of a function.      Alt:  Local variables declared near first usage.      Ref:  [8] FAQ 424---------------------------------------------------------------------(c) References---------------------------------------------------------------------[1] Style and Syntax, Dan Saks, C/C++ Users Journal, Vol. 13, No. 10,     October 1995[2] Effective C++, Scott Meyers, Addison-Wesley, 1992[3] More Effective C++, Scott Meyers, Addison-Wesley, 1996[4] Taligent's Guide to Designing Programs, Addison-Wesley, 1994[5] Code Complete, Steve McConnell, Microsoft Press, 1993[6] Debugging the Development Process, Steve Maguire, Microsoft     Press, 1994[8] C++ FAQs, Cline/Lomow, Addison-Wesley, 1995[9] C++ Programming Style, Tom Cargill, Addison-Wesley, 1992[10] The C++ Programming Language, 2nd Edition, Bjarne Stroustrup,      Addison-Wesley, 1991+-----------------------------------------------------------------------+| Peter C. Murray  (pcm@vus002.vic.npb.telecom.com.au)                  ||                                                                       || class Disclaimer : public StdDisclaimer { /* It was all my fault */ };||                                                                       || - Emergency Services Systems Development                              || - Information Technology Group,  Telecom (Telstra) Australia          |+-----------------------------------------------------------------------+      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]