X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/1a7f306263595bff3b74e96e4c2bee6f0a008500..f47cd02d71ef728221b29bf6bb3254ad85a12310:/docs/html/standard.htm diff --git a/docs/html/standard.htm b/docs/html/standard.htm index 15ee6ef106..9bd3acac53 100644 --- a/docs/html/standard.htm +++ b/docs/html/standard.htm @@ -50,11 +50,18 @@ C++ portability guide by David Williams.
  • Don't use STL
  • Don't declare variables inside for()
  • Don't use nested classes
    • + +
    +
  • Other compiler limitations
    • +
    1. Use ternary operator ?: carefully
      2. +
    2. Don't use initializers with automatic arrays
      3. +
    3. Always have at least one constructor in a class with destructor

  • General recommendations
      • +
    1. No C++ comments in C code>
    2. No global variables with constructor
    3. Turn on all warnings and eradicate them
    4. Don't rely on sizeof(int) == 2...
      5. @@ -71,6 +78,7 @@ C++ portability guide by David Williams.
    5. Avoid carriage returns in cross-platform code
    6. Use only lower letter filenames
    7. Terminate the files with a new-line
      8. +
    8. Avoid globals differing by case only

  • Style choices
    • @@ -104,8 +112,7 @@ C++ portability guide by David Williams.
  • More about naming conventions
    1. Use wx or WX prefix for all public symbols
      2. -
    2. Use WXDLLEXPORT with all classes/functions in - wxMSW/common code
      3. +
    3. Use WXDLLEXPORT with all classes/functions in wxMSW/common code
    4. Use Set/Get prefixes for accessors
    5. wxNAMING_CONSTANTS
    @@ -331,7 +338,17 @@ you can try the following:

    A nice side effect is that you don't need to recompile all the files including the header if you change the PrivateLibClass declaration (it's an example of a more general interface/implementation separation idea). + +
    +

  • Other compiler limitations

    • +This section lists the less obvious limitations of the current C++ compilers +which are less restrictive than the ones mentioned in the previous section but +are may be even more dangerous as a program which compiles perfectly well on +some platform and seems to use only standard C++ featurs may still fail to +compile on another platform and/or with another compiler. + +

    1. Use ternary operator ?: carefully

      2. The ternary operator ?: shouldn't be used with objects (i.e. if any of its operands are objects) because some compilers (notable Borland C++) fail @@ -350,6 +367,24 @@ to compile such code. else s = s2; + +

    2. Don't use initializers with automatic arrays

      3. +The initializers for automatic array variables are not supported by some older +compilers. For example, the following line +

      +    int daysInMonth[12] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };
+
      +will fail to compile with HP-UX C++ compiler. +

      Workaround: either make the array static or initialize each item +separately: in the (stupid) example above, the array should be definitely +declared as static const (assuming that the leap years are dealt with +elsewhere somehow...) which is ok. When an array is really not const, you +should initialize each element separately. + +

    3. Always have at least one constructor in a class with destructor

      4. +It is a good rule to follow in general, but some compilers (HP-UX) enforce it. +So even if you are sure that the default constructor for your class is ok but +it has a destructor, remember to add an empty default constructor to it.


    @@ -361,6 +396,18 @@ which must be followed if you wish to write correct, i.e. working, progra also contains some C/C++ specific remarks in the end which are less important.
      +

    1. No C++ comments in C code>

      2. +Never use C++ comments in C code - not all C compilers/preprocessors +understand them. Although we're mainly concerned with C++ here, there are +several files in wxWindows sources tree which are compiled with C compiler. +Among them are include/wx/setup.h and include/wx/expr.h. + +Another thing related to C vs C++ preprocessor differences is that some old C +preprocessors require that all directives start in the first column (while +it's generally allowed to have any amount of whitespace before them in C++), +so you should start them in the beginning of the line in files which are +compiled with C compiler. +

    2. No global variables with constructors

      3. In C++, the constructors of global variables are called before the main() function (or WinMain() or any other program entry point) @@ -577,6 +624,13 @@ While DOS/Windows compilers don't seem to mind, their Unix counterparts don't like files without terminating new-line. Such files also give a warning message when loaded to vim (the Unix programmer's editor of choice :-)), so please think about terminating the last line. + +

    3. Avoid globals differing by case only

      4. +The linker on VMS is case-insensitive. Therefore all external variables and +functions which differ only in case are not recognized by the linker as +different, so all externals should differ in more than the case only: +i.e. GetId is the same as GetID. +


    @@ -710,8 +764,8 @@ the right header for given platform. Any new headers should conform to this setup as well to allow including <wx/foo.h> on any platform.

    Note that wxWindows implementation files should use quotes when including wxWindows -headers, not angled brackets. Applications should use angled brackets. There -is a reason for it (can anyone remember what this is?). +headers, not angled brackets. Applications should use angled brackets. This +ensures that the dependencies are correctly handled by the compiler.

    • Include guards

    To minimize the compile time C++ programmers often use so called include @@ -815,12 +869,6 @@ WXDLLEXPORT_DATA(extern wxApp*) wxTheApp; The reason for the strange syntax for data is that some compilers use different keyword ordering for exporting data. -

    There also several other places where you should take care of shared -library case: all IMPLEMENT_xxx macros which are usually used in the -corresponding .cpp files must be taken inside -"#if !USE_SHARED_LIBRARY" and in the #if USE_SHARED_LIBRARY -case you should put them inside common/cmndata.cpp file. -

    • Use Set/Get prefixes for accessors

    There is a convention in wxWindows to prefix the accessors (i.e. any simple, in general, inline function which does nothing else except changing or returning