blob: e0c18427bfd7e177f313bbbfc3171083d6444be2 (
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
|
= Usage of {cpp} within RNP
This is a provisional document reflecting the recent conversion from C
to {cpp}. It should be revisited as experience with using {cpp} within RNP
codebase increases.
== Encouraged Features
These are features which seem broadly useful, their downsides are minimal
and well understood.
- STL types std::vector, std::string, std::unique_ptr, std::map
- RAII techniques (destructors, smart pointers) to minimize use of
goto to handle cleanup.
- Value types, that is to say types which simply encapsulate some
data.
- std::function or virtual functions to replace function pointers.
- Prefer virtual functions only on "interface" classes (with no data),
and derive only one level of classes from this interface class.
- Anonymous namespaces are an alternative to `static` functions.
== Questionable Features
These are features that may be useful in certain situations, but should
be used carefully.
- Exceptions. While convenient, they do have a non-zero cost in runtime
and binary size.
== Forbidden Features
These are {cpp} features that simply should be avoided, at least until a
very clear use case for them has been identified and no other approach
suffices.
- RTTI. This has a significant runtime cost and usually there are
better alternatives.
- Multiple inheritance. This leads to many confusing and problematic
scenarios.
- Template metaprogramming. If you have a problem, and you think
template metaprogramming will solve it, now you have two problems,
and one of them is incomprehensible.
|
