This guide is intended for people who are (or intending to start) writing code -for wxWindows class library. +for wxWindows class library.
The guide is separated into two parts: the first one addresses the general @@ -35,7 +35,7 @@ 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 +HREF="http://www.mozilla.org/hacking/portable-cpp.html" target=_top> C++ portability guide by David Williams.
@@ -52,14 +52,22 @@ C++ portability guide by David Williams.
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).
+
+
+
+
+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. + +
+ 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 +to compile such code. +
Workaround: use if/else instead. +
+ wxString s1, s2; + + // Borland C++ won't compile the line below + wxString s = s1.Len() < s2.Len() ? s1 : s2; + + // but any C++ compiler will compile this + wxString s; + if ( s1.Len() < s2.Len() ) + s = s1; + else + s = s2; ++ +
+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. + +
+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.
+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. +
In C++, the constructors of global variables are called before the main() function (or WinMain() or any other program entry point) @@ -444,6 +509,70 @@ instead of The reason is simple: if there are any /* ... */ comments inside ... the second version will, of course, miserably fail. +
+ +You should avoid having overloaded virtual methods in a base class because if +any of them is overriden in a derived class, then all others must be overriden +as well or it would be impossible to call them on an object of derived class. + +For example, the following code: + +
+ class Base
+ {
+ public:
+ virtual void Read(wxFile& file);
+ virtual void Read(const wxString& filename);
+ };
+
+ class Derived : public Base
+ {
+ public:
+ virtual void Read(wxFile& file) { ... }
+ };
+
+ ...
+
+ Derived d;
+ d.Read("some_filename"); // compile error here!
+
+
+will fail to compile because the base class function taking filename
+is hidden by the virtual function overriden in the derived class (this is
+known as [virtual] function name hiding problem in C++).
+
++The standard solution to this problem in wxWindows (where we have such +situations quite often) is to make both Read() functions not virtual +and introduce a single virtual function DoRead(). Usually, it makes +sense because the function taking a filename is (again, usually) implemented +in terms of the function reading from a file anyhow (but making only this +functions not virtual won't solve the above problem!). +
+So, the above declarations should be written as: +
+ class Base
+ {
+ public:
+ void Read(wxFile& file);
+ void Read(const wxString& filename);
+
+ protected:
+ virtual void DoRead(wxFile& file);
+ };
+
+ class Derived : public Base
+ {
+ protected:
+ virtual void DoRead(wxFile& file) { ... }
+ };
+
+
+This technique is widely used in many of wxWindows classes - for example,
+wxWindow has more than a dozen of DoXXX() functions which
+allows to have many overloaded versions of commonly used methods such as
+SetSize()
+
Some compilers don't pay any attention to extra semicolons on top level, as in
@@ -495,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. + +
+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. +
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. -
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