blob: ff3018ced1ba41ec6bc627dd8d085a3a814531da (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
CppUnit's coding guidelines for portability:
--------------------------------------------
- don't explicitly declare CppUnit namespace, instead use macro
CPPUNIT_NS_BEGIN and CPPUNIT_NS_END.
- don't explicitly use 'CppUnit' to refer to class in CppUnit namespace,
instead use macro CPPUNIT_NS which expands to either 'CppUnit' or
nothing depending on the configuration.
- don't use the 'using directive', always use full qualification. For STL,
always use std::.
- don't use the mutable keyword, instead do a const cast.
- don't use default template parameters. If needed, use STLPort wrapper
technic (see include/cppunit/portability/).
- don't use templatized member functions (template method declared inside a
class), instead declares them as simple template functions (even
mainstream compiler such as VC++ 6 as trouble with them).
- don't use default parameter value in template function. Not supported
by all compiler (on OS/390 for instance).
- dereferencing containers must be done by (*ref_ptr).data instead of
ref_ptr->data.
- don't use C++11/C++14 features in non-optional code
In brief, it should be possible to compile CppUnit on a C++ compiler that do
not have the following features:
- template default parameters
- templatized member functions (that is a template function declared within a
class).
As such, usage of those features should always be optional.
CppUnit's version control system management
--------------------------------------------
- only commit patches that are known to build; other commits might just be reverted
to allow bisecting
- work in feature branches until your feature is ready to merge, if the feature
may break the build ask for review on the libreoffice developer mailing list
- new features and patches without bug report only in master
and not in stable branches
|
