diff --git a/docs/html/standard.htm b/docs/html/standard.htm index 196224130c..61d507667e 100644 --- a/docs/html/standard.htm +++ b/docs/html/standard.htm @@ -34,7 +34,7 @@ variety of platforms. The second part details the wxWindows code organization an its goal it to make wxWindows as uniform as possible without imposing too many restrictions on the programmer.

-Acknowledgements: This guide is partly based on C++ portability guide by David Williams. @@ -100,14 +100,15 @@ C++ portability guide by David Williams.

  • Indent your code with 4 spaces (no tabs!)
  • Order of parts in a class declarations
    • - +
  • More about naming conventions
    1. Use wx or WX prefix for all public symbols
      2. -
    2. Use WXDLLEXPORT with all classes/functions in +
    3. Use WXDLLEXPORT with all classes/functions in wxMSW/common code
    4. Use Set/Get prefixes for accessors
      5. +
    5. wxNAMING_CONSTANTS

    @@ -123,7 +124,7 @@ C++ portability guide by David Williams.

    General C++ Rules

    - +

  • Don't use RTTI

    • RTTI stands for Run-Time Type Information and there is probably no other reason not to use it except the portability issue and the fact that it adds @@ -240,7 +241,7 @@ reason not to use it except the portability issue and the fact that it adds in the implementations I'm aware of).

    Workaround: use wxWindows RTTI system which allows you to do almost everything which the new C++ RTTI, except that, of course, you have to use -macros instead of the (horrible looking, BTW) dynamic_cast. +macros instead of the (horrible looking, BTW) dynamic_cast.

  • Don't use namespaces

    • This topic is subject to change with time, however for the moment all wxWindows @@ -312,17 +313,17 @@ you can try the following: private: class PrivateLibClass *m_pObject; }; - + // in the .cpp file class PrivateLibClass { ... }; - + PublicLibClass::PublicLibClass() { m_pObject = new PrivateLibClass; - + ... } - + PublicLibClass::~PublicLibClass() { delete m_pObject; @@ -337,14 +338,14 @@ an example of a more general interface/implementation separation idea).

  • General recommendations

    • While the recommendations in the previous section may not apply to you if you're only working with perfect compilers which implement the very newest directives of -C++ standard, this section contains compiler- (and language-) independent advice +C++ standard, this section contains compiler- (and language-) independent advice which must be followed if you wish to write correct, i.e. working, programs. It -also contains some C/C++ specific remarks in the end which are less +also contains some C/C++ specific remarks in the end which are less important.

    1. No global variables with constructors

      2. In C++, the constructors of global variables are called before the -main() function (or WinMain() or any other program entry point) +main() function (or WinMain() or any other program entry point) starts executing. Thus, there is no possibility to initialize anything before the constructor call. The order of construction is largely implementation-defined, meaning that there is no guarantee that one global @@ -423,7 +424,7 @@ sizes are different. A small table illustrates it quite well: Although close to the heart of many C programmers (I plead guilty), code like classical if ( (c = getchar()) != EOF ) is bad because it prevents you from enabling "assignment in conditional expression" warning (see also -above) warning which is helpful to detect common +above) which is helpful to detect common mistypes like if ( x = 2 ) instead of if ( x == 2 ).

    2. Use #if 0 rather than comments to temporarily @@ -495,10 +496,10 @@ 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.
    - +
  • Style choices

    • - All wxWindows specific style guidelines are specified in the next + All wxWindows specific style guidelines are specified in the next section, here are the choices which are not completely arbitrary, but have some deeper and not wxWindows-specific meaning. @@ -518,9 +519,9 @@ following code fragment is: void Foo::Bar(int x_) { ... - + x = x_; - + ... } @@ -591,7 +592,7 @@ However, the const keyword is confusing here, adds nothing to the code and even cannot be removed if Foo() is virtual and overridden (because the names are mangled differently). So, for arguments passed by value you shouldn't use const. -

    Of course, it doesn't apply to functions such as +

    Of course, it doesn't apply to functions such as void PrintMessage(const char *text) where const is mandatory. @@ -607,7 +608,7 @@ The wxWindows files for each supported platform have their own subdirectories in "include" and "src". So, for example, there is "src/msw", "include/gtk" etc. There are also two special subdirectories called "common" and "generic". The common subdirectory contains the files which are platform -independent (wxObject, wxString, ...) and the generic one the generic +independent (wxObject, wxString, ...) and the generic one the generic implementations of GUI widgets, i.e. those which use only other wxWindows classes to implement them. For the platforms where the given functionality cannot be implemented natively, the generic implementation is used and the native @@ -712,12 +713,12 @@ usage 'public domain' (the copyright holder does not assert the copyright).

    • Indent your code with 4 spaces (no tabs!)

    • Order of parts in a class declarations

    - +

  • More about naming conventions

      2. Use wx or WX prefix for all public symbols. wx should be used for functions and classes, WX for macros. -

    2. Use WXDLLEXPORT with all classes/functions in +

    3. Use WXDLLEXPORT with all classes/functions in wxMSW/common code The title says it all - every public (in the sense that it is not internal to the library) function or class should have WXDLLEXPORT macro in its @@ -734,14 +735,33 @@ 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 +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.

      5. 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 +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 the value of a member variable) with either Set or Get. + +

      6. wxNAMING_CONSTANTS

      +The constants in wxWindows code should be defined using enum C++ +keyword (and not with #define or static const int). They +should be declared in the global scope (and not inside class declaration) and +their names should start with a wx prefix. Finally, the constants +should be in all capital letters (except the first 2) to make it easier to +distinguish them from the variables with underscores separating the words. + +

      For example, file-related constants should be declared like this: +

      +enum
+{
+    wxFILEOPEN_READ,
+    wxFILEOPEN_WRITE,
+    wxFILEOPEN_READWRITE
+};
+
      +

  • Miscellaneous

    • @@ -751,7 +771,7 @@ It's really a trivial piece of advice, but remember that using forward declarati instead of including the header of corresponding class is better because not only does it minimize the compile time, it also simplifies the dependencies between different source files. -

    On a related subject, in general, you should try not to include other +

    On a related subject, in general, you should try not to include other headers from a header file.

    • Use debugging macros

    @@ -764,7 +784,7 @@ stubs for not (yet) implemented functions which silently return incorrect values - otherwise, a person using a not implemented function has no idea that it is, in fact, not implemented.

    As all debugging macros only do something useful if the symbol -__DEBUG__ is defined, you should compile your programs in debug mode to profit +__WXDEBUG__ is defined, you should compile your programs in debug mode to profit from them.