Skip to content

Commit e87397d

Browse files
authored
Merge pull request #192 from N-Dekker/Exclude-low-level-utilities-from-initialization-rule
DOC: Adjust initialization rule for padding data, smart pointers, etc.
2 parents 6525a5c + 6d5f5b5 commit e87397d

File tree

1 file changed

+17
-2
lines changed

1 file changed

+17
-2
lines changed

SoftwareGuide/Latex/Appendices/CodingStyleGuide.tex

Lines changed: 17 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1621,8 +1621,23 @@ \section{Initialization and Assignment}
16211621
\end{minted}
16221622
\normalsize
16231623
1624-
Smart pointers need not to be initialized, since they initialize themselves
1625-
to the \code{null} pointer, so they are the sole exception to the above rule.
1624+
Exceptions to this guideline:
1625+
1626+
Private data members that are just there to add padding bytes between other
1627+
(member) variables (typically to avoid false sharing in the context of
1628+
multi-threading) should not be initialized. Such a padding data member is
1629+
typically declared as a C-style array of a (possibly unsigned) character type.
1630+
1631+
A data member that is declared as \code{std::unique\_ptr<T>} or
1632+
\code{itk::SmartPointer<T>} should not have an empty \code{\{\}} initializer at
1633+
its declaration, at least for now, because of a GCC issue (prior to GCC release
1634+
9.2), which would cause compilation errors when the type \code{T} is an
1635+
incomplete (forward declared) class type.
1636+
1637+
Another exception is made for low level utility classes for which data member
1638+
initialization would cause a significant performance penalty. This is why for
1639+
example \code{FixedArray::m\_InternalArray} and \code{Index::m\_InternalArray}
1640+
do not have a default member initializer.
16261641
16271642
Note that all numeric data members must be initialized using the appropriate
16281643
ITK's \code{NumericTraits} static method.

0 commit comments

Comments
 (0)