xref: /aosp_15_r20/external/eigen/doc/ClassHierarchy.dox (revision bf2c37156dfe67e5dfebd6d394bad8b2ab5804d4)
1*bf2c3715SXin Linamespace Eigen {
2*bf2c3715SXin Li
3*bf2c3715SXin Li/** \page TopicClassHierarchy The class hierarchy
4*bf2c3715SXin Li
5*bf2c3715SXin LiThis page explains the design of the core classes in Eigen's class hierarchy and how they fit together. Casual
6*bf2c3715SXin Liusers probably need not concern themselves with these details, but it may be useful for both advanced users
7*bf2c3715SXin Liand Eigen developers.
8*bf2c3715SXin Li
9*bf2c3715SXin Li\eigenAutoToc
10*bf2c3715SXin Li
11*bf2c3715SXin Li
12*bf2c3715SXin Li\section TopicClassHierarchyPrinciples Principles
13*bf2c3715SXin Li
14*bf2c3715SXin LiEigen's class hierarchy is designed so that virtual functions are avoided where their overhead would
15*bf2c3715SXin Lisignificantly impair performance. Instead, Eigen achieves polymorphism with the Curiously Recurring Template
16*bf2c3715SXin LiPattern (CRTP). In this pattern, the base class (for instance, \c MatrixBase) is in fact a template class, and
17*bf2c3715SXin Lithe derived class (for instance, \c Matrix) inherits the base class with the derived class itself as a
18*bf2c3715SXin Litemplate argument (in this case, \c Matrix inherits from \c MatrixBase<Matrix>). This allows Eigen to
19*bf2c3715SXin Liresolve the polymorphic function calls at compile time.
20*bf2c3715SXin Li
21*bf2c3715SXin LiIn addition, the design avoids multiple inheritance. One reason for this is that in our experience, some
22*bf2c3715SXin Licompilers (like MSVC) fail to perform empty base class optimization, which is crucial for our fixed-size
23*bf2c3715SXin Litypes.
24*bf2c3715SXin Li
25*bf2c3715SXin Li
26*bf2c3715SXin Li\section TopicClassHierarchyCoreClasses The core classes
27*bf2c3715SXin Li
28*bf2c3715SXin LiThese are the classes that you need to know about if you want to write functions that accept or return Eigen
29*bf2c3715SXin Liobjects.
30*bf2c3715SXin Li
31*bf2c3715SXin Li  - Matrix means plain dense matrix. If \c m is a \c %Matrix, then, for instance, \c m+m is no longer a
32*bf2c3715SXin Li    \c %Matrix, it is a "matrix expression".
33*bf2c3715SXin Li  - MatrixBase means dense matrix expression. This means that a \c %MatrixBase is something that can be
34*bf2c3715SXin Li    added, matrix-multiplied, LU-decomposed, QR-decomposed... All matrix expression classes, including
35*bf2c3715SXin Li    \c %Matrix itself, inherit \c %MatrixBase.
36*bf2c3715SXin Li  - Array means plain dense array. If \c x is an \c %Array, then, for instance, \c x+x is no longer an
37*bf2c3715SXin Li    \c %Array, it is an "array expression".
38*bf2c3715SXin Li  - ArrayBase means dense array expression. This means that an \c %ArrayBase is something that can be
39*bf2c3715SXin Li    added, array-multiplied, and on which you can perform all sorts of array operations... All array
40*bf2c3715SXin Li    expression classes, including \c %Array itself, inherit \c %ArrayBase.
41*bf2c3715SXin Li  - DenseBase means dense (matrix or array) expression. Both \c %ArrayBase and \c %MatrixBase inherit
42*bf2c3715SXin Li    \c %DenseBase. \c %DenseBase is where all the methods go that apply to dense expressions regardless of
43*bf2c3715SXin Li    whether they are matrix or array expressions. For example, the \link DenseBase::block() block(...) \endlink
44*bf2c3715SXin Li    methods are in \c %DenseBase.
45*bf2c3715SXin Li
46*bf2c3715SXin Li\section TopicClassHierarchyBaseClasses Base classes
47*bf2c3715SXin Li
48*bf2c3715SXin LiThese classes serve as base classes for the five core classes mentioned above. They are more internal and so
49*bf2c3715SXin Liless interesting for users of the Eigen library.
50*bf2c3715SXin Li
51*bf2c3715SXin Li  - PlainObjectBase means dense (matrix or array) plain object, i.e. something that stores its own dense
52*bf2c3715SXin Li    array of coefficients. This is where, for instance, the \link PlainObjectBase::resize() resize() \endlink
53*bf2c3715SXin Li    methods go. \c %PlainObjectBase is inherited by \c %Matrix and by \c %Array. But above, we said that
54*bf2c3715SXin Li    \c %Matrix inherits \c %MatrixBase and \c %Array inherits \c %ArrayBase. So does that mean multiple
55*bf2c3715SXin Li    inheritance? No, because \c %PlainObjectBase \e itself inherits \c %MatrixBase or \c %ArrayBase depending
56*bf2c3715SXin Li    on whether we are in the matrix or array case. When we said above that \c %Matrix inherited
57*bf2c3715SXin Li    \c %MatrixBase, we omitted to say it does so indirectly via \c %PlainObjectBase. Same for \c %Array.
58*bf2c3715SXin Li  - DenseCoeffsBase means something that has dense coefficient accessors. It is a base class for
59*bf2c3715SXin Li    \c %DenseBase. The reason for \c %DenseCoeffsBase to exist is that the set of available coefficient
60*bf2c3715SXin Li    accessors is very different depending on whether a dense expression has direct memory access or not (the
61*bf2c3715SXin Li    \c DirectAccessBit flag). For example, if \c x is a plain matrix, then \c x has direct access, and
62*bf2c3715SXin Li    \c x.transpose() and \c x.block(...) also have direct access, because their coefficients can be read right
63*bf2c3715SXin Li    off memory, but for example, \c x+x does not have direct memory access, because obtaining any of its
64*bf2c3715SXin Li    coefficients requires a computation (an addition), it can't be just read off memory.
65*bf2c3715SXin Li  - EigenBase means anything that can be evaluated into a plain dense matrix or array (even if that would
66*bf2c3715SXin Li    be a bad idea). \c %EigenBase is really the absolute base class for anything that remotely looks like a
67*bf2c3715SXin Li    matrix or array. It is a base class for \c %DenseCoeffsBase, so it sits below all our dense class
68*bf2c3715SXin Li    hierarchy, but it is not limited to dense expressions. For example, \c %EigenBase is also inherited by
69*bf2c3715SXin Li    diagonal matrices, sparse matrices, etc...
70*bf2c3715SXin Li
71*bf2c3715SXin Li
72*bf2c3715SXin Li\section TopicClassHierarchyInheritanceDiagrams Inheritance diagrams
73*bf2c3715SXin Li
74*bf2c3715SXin LiThe inheritance diagram for Matrix looks as follows:
75*bf2c3715SXin Li
76*bf2c3715SXin Li<pre>
77*bf2c3715SXin LiEigenBase&lt;%Matrix&gt;
78*bf2c3715SXin Li  <-- DenseCoeffsBase&lt;%Matrix&gt;    (direct access case)
79*bf2c3715SXin Li    <-- DenseBase&lt;%Matrix&gt;
80*bf2c3715SXin Li      <-- MatrixBase&lt;%Matrix&gt;
81*bf2c3715SXin Li        <-- PlainObjectBase&lt;%Matrix&gt;    (matrix case)
82*bf2c3715SXin Li          <-- Matrix
83*bf2c3715SXin Li</pre>
84*bf2c3715SXin Li
85*bf2c3715SXin LiThe inheritance diagram for Array looks as follows:
86*bf2c3715SXin Li
87*bf2c3715SXin Li<pre>
88*bf2c3715SXin LiEigenBase&lt;%Array&gt;
89*bf2c3715SXin Li  <-- DenseCoeffsBase&lt;%Array&gt;    (direct access case)
90*bf2c3715SXin Li    <-- DenseBase&lt;%Array&gt;
91*bf2c3715SXin Li      <-- ArrayBase&lt;%Array&gt;
92*bf2c3715SXin Li        <-- PlainObjectBase&lt;%Array&gt;    (array case)
93*bf2c3715SXin Li          <-- Array
94*bf2c3715SXin Li</pre>
95*bf2c3715SXin Li
96*bf2c3715SXin LiThe inheritance diagram for some other matrix expression class, here denoted by \c SomeMatrixXpr, looks as
97*bf2c3715SXin Lifollows:
98*bf2c3715SXin Li
99*bf2c3715SXin Li<pre>
100*bf2c3715SXin LiEigenBase&lt;SomeMatrixXpr&gt;
101*bf2c3715SXin Li  <-- DenseCoeffsBase&lt;SomeMatrixXpr&gt;    (direct access or no direct access case)
102*bf2c3715SXin Li    <-- DenseBase&lt;SomeMatrixXpr&gt;
103*bf2c3715SXin Li      <-- MatrixBase&lt;SomeMatrixXpr&gt;
104*bf2c3715SXin Li        <-- SomeMatrixXpr
105*bf2c3715SXin Li</pre>
106*bf2c3715SXin Li
107*bf2c3715SXin LiThe inheritance diagram for some other array expression class, here denoted by \c SomeArrayXpr, looks as
108*bf2c3715SXin Lifollows:
109*bf2c3715SXin Li
110*bf2c3715SXin Li<pre>
111*bf2c3715SXin LiEigenBase&lt;SomeArrayXpr&gt;
112*bf2c3715SXin Li  <-- DenseCoeffsBase&lt;SomeArrayXpr&gt;    (direct access or no direct access case)
113*bf2c3715SXin Li    <-- DenseBase&lt;SomeArrayXpr&gt;
114*bf2c3715SXin Li      <-- ArrayBase&lt;SomeArrayXpr&gt;
115*bf2c3715SXin Li        <-- SomeArrayXpr
116*bf2c3715SXin Li</pre>
117*bf2c3715SXin Li
118*bf2c3715SXin LiFinally, consider an example of something that is not a dense expression, for instance a diagonal matrix. The
119*bf2c3715SXin Licorresponding inheritance diagram is:
120*bf2c3715SXin Li
121*bf2c3715SXin Li<pre>
122*bf2c3715SXin LiEigenBase&lt;%DiagonalMatrix&gt;
123*bf2c3715SXin Li  <-- DiagonalBase&lt;%DiagonalMatrix&gt;
124*bf2c3715SXin Li    <-- DiagonalMatrix
125*bf2c3715SXin Li</pre>
126*bf2c3715SXin Li
127*bf2c3715SXin Li
128*bf2c3715SXin Li*/
129*bf2c3715SXin Li}
130