Commit cd7a35db authored by David Fairbrother's avatar David Fairbrother
Browse files

Add note about using modern nested syntax to standards

This way we officially acknowledge we use it, and prefer to use it
because of the reduction in boilerplate
parent 128f15ef
......@@ -66,6 +66,7 @@ order:
- Mantid headers from other projects
- 3rd party library headers
- System ``#include`` directives
- Any required namespace(s)
- Forward declarations of other classes
- Global constants, enumerations & typedefs
- Doxygen class description
......@@ -183,22 +184,23 @@ Preprocessor
Classes and Namespaces
^^^^^^^^^^^^^^^^^^^^^^
1. There should be only one class or namespace declared in each header
#. There should be only one class or namespace declared in each header
file. This recommendation should only be relaxed where classes are
closely tied together.
2. There should be only one class or namespace defined per body file
#. Namespaces should use the C++-17 nested specifier e.g. `namespace A::B{}`
#. There should be only one class or namespace defined per body file
(unless classes are closely tied as in (1) above). All the
definitions for that class/namespace should be in the one file
(unless this yields a source file that is unmanageably large).
3. Data members should be private. Access to data from other classes
#. Data members should be private. Access to data from other classes
should only be through protected or public methods (or by
‘friends’, but see item 8). Inside a large class, consider
reserving direct access to private data members for a smaller
manageable core of member functions.
4. All constructors for a class must initialise all its member variables
#. All constructors for a class must initialise all its member variables
that do not have a default constructor (including primitive and
pointer types).
5. All base classes must have a virtual destructor.
#. All base classes must have a virtual destructor.
- This may be disregarded only in exceptional circumstances when
the overhead of a virtual-table would significantly affect
......@@ -211,26 +213,26 @@ Classes and Namespaces
easily be ignored or misunderstood, particularly by inexperienced
developers
6. Classes’ constructors and destructors must not call their own virtual
#. Classes’ constructors and destructors must not call their own virtual
member functions, directly or indirectly. (C++ does not resolve such
function calls polymorphically.)
7. Do not define special members functions when they would be
#. Do not define special members functions when they would be
identical to those automatically generated by the compiler. Use ``=
delete`` to remove invalid compiler-generated versions. Consider
following the `rule-of-zero <https://rmf.io/cxx11/rule-of-zero/>`__
and writing an additional class for resource management.
8. The use of ``friend`` should be avoided and its use requires
#. The use of ``friend`` should be avoided and its use requires
justification. As an exception, overloads of the ``<<`` and ``>>``
operators for serialising the class may be declared as ``friend``.
9. Use of multiple inheritance should be restricted to cases in which
#. Use of multiple inheritance should be restricted to cases in which
the second and subsequent base classes are all interfaces. (An
interface in this context is a class consisting only of pure virtual
functions.).
10. Virtual inheritance should only be used when the base class
involved is an interface.
11. Unions and bitfields should only be used where essential for
performance, or where required for interfacing with a third party
library.
#. Virtual inheritance should only be used when the base class
involved is an interface.
#. Unions and bitfields should only be used where essential for
performance, or where required for interfacing with a third party
library.
Mantid Namespaces
-----------------
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment