Sean Silva | 36be1ae | 2012-10-05 03:32:01 +0000 | [diff] [blame] | 1 | .. _how-to-set-up-llvm-style-rtti: |
| 2 | |
| 3 | ====================================================== |
| 4 | How to set up LLVM-style RTTI for your class hierarchy |
| 5 | ====================================================== |
| 6 | |
| 7 | .. sectionauthor:: Sean Silva <silvas@purdue.edu> |
| 8 | |
| 9 | .. contents:: |
| 10 | |
| 11 | Background |
| 12 | ========== |
| 13 | |
| 14 | LLVM avoids using C++'s built in RTTI. Instead, it pervasively uses its |
| 15 | own hand-rolled form of RTTI which is much more efficient and flexible, |
| 16 | although it requires a bit more work from you as a class author. |
| 17 | |
| 18 | A description of how to use LLVM-style RTTI from a client's perspective is |
| 19 | given in the `Programmer's Manual <ProgrammersManual.html#isa>`_. This |
| 20 | document, in contrast, discusses the steps you need to take as a class |
| 21 | hierarchy author to make LLVM-style RTTI available to your clients. |
| 22 | |
| 23 | Before diving in, make sure that you are familiar with the Object Oriented |
| 24 | Programming concept of "`is-a`_". |
| 25 | |
| 26 | .. _is-a: http://en.wikipedia.org/wiki/Is-a |
| 27 | |
| 28 | Basic Setup |
| 29 | =========== |
| 30 | |
| 31 | This section describes how to set up the most basic form of LLVM-style RTTI |
| 32 | (which is sufficient for 99.9% of the cases). We will set up LLVM-style |
| 33 | RTTI for this class hierarchy: |
| 34 | |
| 35 | .. code-block:: c++ |
| 36 | |
| 37 | class Shape { |
| 38 | public: |
Dmitri Gribenko | 07d1c21 | 2012-10-05 20:52:13 +0000 | [diff] [blame] | 39 | Shape() {} |
Sean Silva | 36be1ae | 2012-10-05 03:32:01 +0000 | [diff] [blame] | 40 | virtual double computeArea() = 0; |
| 41 | }; |
| 42 | |
| 43 | class Square : public Shape { |
| 44 | double SideLength; |
| 45 | public: |
| 46 | Square(double S) : SideLength(S) {} |
| 47 | double computeArea() /* override */; |
| 48 | }; |
| 49 | |
| 50 | class Circle : public Shape { |
| 51 | double Radius; |
| 52 | public: |
| 53 | Circle(double R) : Radius(R) {} |
| 54 | double computeArea() /* override */; |
| 55 | }; |
| 56 | |
| 57 | The most basic working setup for LLVM-style RTTI requires the following |
| 58 | steps: |
| 59 | |
| 60 | #. In the header where you declare ``Shape``, you will want to ``#include |
| 61 | "llvm/Support/Casting.h"``, which declares LLVM's RTTI templates. That |
| 62 | way your clients don't even have to think about it. |
| 63 | |
| 64 | .. code-block:: c++ |
| 65 | |
| 66 | #include "llvm/Support/Casting.h" |
| 67 | |
| 68 | |
| 69 | #. In the base class, introduce an enum which discriminates all of the |
| 70 | different classes in the hierarchy, and stash the enum value somewhere in |
| 71 | the base class. |
| 72 | |
| 73 | Here is the code after introducing this change: |
| 74 | |
| 75 | .. code-block:: c++ |
| 76 | |
| 77 | class Shape { |
| 78 | public: |
| 79 | + /// Discriminator for LLVM-style RTTI (dyn_cast<> et al.) |
| 80 | + enum ShapeKind { |
| 81 | + SquareKind, |
| 82 | + CircleKind |
| 83 | + }; |
| 84 | +private: |
| 85 | + const ShapeKind Kind; |
| 86 | +public: |
| 87 | + ShapeKind getKind() const { return Kind; } |
| 88 | + |
Dmitri Gribenko | 07d1c21 | 2012-10-05 20:52:13 +0000 | [diff] [blame] | 89 | Shape() {} |
Sean Silva | 36be1ae | 2012-10-05 03:32:01 +0000 | [diff] [blame] | 90 | virtual double computeArea() = 0; |
| 91 | }; |
| 92 | |
| 93 | You will usually want to keep the ``Kind`` member encapsulated and |
| 94 | private, but let the enum ``ShapeKind`` be public along with providing a |
| 95 | ``getKind()`` method. This is convenient for clients so that they can do |
| 96 | a ``switch`` over the enum. |
| 97 | |
| 98 | A common naming convention is that these enums are "kind"s, to avoid |
| 99 | ambiguity with the words "type" or "class" which have overloaded meanings |
| 100 | in many contexts within LLVM. Sometimes there will be a natural name for |
| 101 | it, like "opcode". Don't bikeshed over this; when in doubt use ``Kind``. |
| 102 | |
| 103 | You might wonder why the ``Kind`` enum doesn't have an entry for |
| 104 | ``Shape``. The reason for this is that since ``Shape`` is abstract |
| 105 | (``computeArea() = 0;``), you will never actually have non-derived |
| 106 | instances of exactly that class (only subclasses). See `Concrete Bases |
| 107 | and Deeper Hierarchies`_ for information on how to deal with |
| 108 | non-abstract bases. It's worth mentioning here that unlike |
| 109 | ``dynamic_cast<>``, LLVM-style RTTI can be used (and is often used) for |
| 110 | classes that don't have v-tables. |
| 111 | |
| 112 | #. Next, you need to make sure that the ``Kind`` gets initialized to the |
| 113 | value corresponding to the dynamic type of the class. Typically, you will |
| 114 | want to have it be an argument to the constructor of the base class, and |
| 115 | then pass in the respective ``XXXKind`` from subclass constructors. |
| 116 | |
| 117 | Here is the code after that change: |
| 118 | |
| 119 | .. code-block:: c++ |
| 120 | |
| 121 | class Shape { |
| 122 | public: |
| 123 | /// Discriminator for LLVM-style RTTI (dyn_cast<> et al.) |
| 124 | enum ShapeKind { |
| 125 | SquareKind, |
| 126 | CircleKind |
| 127 | }; |
| 128 | private: |
| 129 | const ShapeKind Kind; |
| 130 | public: |
| 131 | ShapeKind getKind() const { return Kind; } |
| 132 | |
Dmitri Gribenko | 07d1c21 | 2012-10-05 20:52:13 +0000 | [diff] [blame] | 133 | - Shape() {} |
| 134 | + Shape(ShapeKind K) : Kind(K) {} |
Sean Silva | 36be1ae | 2012-10-05 03:32:01 +0000 | [diff] [blame] | 135 | virtual double computeArea() = 0; |
| 136 | }; |
| 137 | |
| 138 | class Square : public Shape { |
| 139 | double SideLength; |
| 140 | public: |
| 141 | - Square(double S) : SideLength(S) {} |
| 142 | + Square(double S) : Shape(SquareKind), SideLength(S) {} |
| 143 | double computeArea() /* override */; |
| 144 | }; |
| 145 | |
| 146 | class Circle : public Shape { |
| 147 | double Radius; |
| 148 | public: |
| 149 | - Circle(double R) : Radius(R) {} |
| 150 | + Circle(double R) : Shape(CircleKind), Radius(R) {} |
| 151 | double computeArea() /* override */; |
| 152 | }; |
| 153 | |
| 154 | #. Finally, you need to inform LLVM's RTTI templates how to dynamically |
| 155 | determine the type of a class (i.e. whether the ``isa<>``/``dyn_cast<>`` |
| 156 | should succeed). The default "99.9% of use cases" way to accomplish this |
| 157 | is through a small static member function ``classof``. In order to have |
| 158 | proper context for an explanation, we will display this code first, and |
| 159 | then below describe each part: |
| 160 | |
| 161 | .. code-block:: c++ |
| 162 | |
| 163 | class Shape { |
| 164 | public: |
| 165 | /// Discriminator for LLVM-style RTTI (dyn_cast<> et al.) |
| 166 | enum ShapeKind { |
| 167 | SquareKind, |
| 168 | CircleKind |
| 169 | }; |
| 170 | private: |
| 171 | const ShapeKind Kind; |
| 172 | public: |
| 173 | ShapeKind getKind() const { return Kind; } |
| 174 | |
Dmitri Gribenko | 07d1c21 | 2012-10-05 20:52:13 +0000 | [diff] [blame] | 175 | Shape(ShapeKind K) : Kind(K) {} |
Sean Silva | 36be1ae | 2012-10-05 03:32:01 +0000 | [diff] [blame] | 176 | virtual double computeArea() = 0; |
| 177 | + |
| 178 | + static bool classof(const Shape *) { return true; } |
| 179 | }; |
| 180 | |
| 181 | class Square : public Shape { |
| 182 | double SideLength; |
| 183 | public: |
| 184 | Square(double S) : Shape(SquareKind), SideLength(S) {} |
| 185 | double computeArea() /* override */; |
| 186 | + |
| 187 | + static bool classof(const Square *) { return true; } |
| 188 | + static bool classof(const Shape *S) { |
| 189 | + return S->getKind() == SquareKind; |
| 190 | + } |
| 191 | }; |
| 192 | |
| 193 | class Circle : public Shape { |
| 194 | double Radius; |
| 195 | public: |
| 196 | Circle(double R) : Shape(CircleKind), Radius(R) {} |
| 197 | double computeArea() /* override */; |
| 198 | + |
| 199 | + static bool classof(const Circle *) { return true; } |
| 200 | + static bool classof(const Shape *S) { |
| 201 | + return S->getKind() == CircleKind; |
| 202 | + } |
| 203 | }; |
| 204 | |
| 205 | Basically, the job of ``classof`` is to return ``true`` if its argument |
| 206 | is of the enclosing class's type. As you can see, there are two general |
| 207 | overloads of ``classof`` in use here. |
| 208 | |
| 209 | #. The first, which just returns ``true``, means that if we know that the |
| 210 | argument of the cast is of the enclosing type *at compile time*, then |
| 211 | we don't need to bother to check anything since we already know that |
| 212 | the type is convertible. This is an optimization for the case that we |
| 213 | statically know the conversion is OK. |
| 214 | |
| 215 | #. The other overload takes a pointer to an object of the base of the |
| 216 | class hierarchy: this is the "general case" of the cast. We need to |
| 217 | check the ``Kind`` to dynamically decide if the argument is of (or |
| 218 | derived from) the enclosing type. |
| 219 | |
| 220 | To be more precise, let ``classof`` be inside a class ``C``. Then the |
| 221 | contract for ``classof`` is "return ``true`` if the argument is-a |
| 222 | ``C``". As long as your implementation fulfills this contract, you can |
| 223 | tweak and optimize it as much as you want. |
| 224 | |
| 225 | Although for this small example setting up LLVM-style RTTI seems like a lot |
| 226 | of "boilerplate", if your classes are doing anything interesting then this |
| 227 | will end up being a tiny fraction of the code. |
| 228 | |
| 229 | Concrete Bases and Deeper Hierarchies |
| 230 | ===================================== |
| 231 | |
| 232 | For concrete bases (i.e. non-abstract interior nodes of the inheritance |
| 233 | tree), the ``Kind`` check inside ``classof`` needs to be a bit more |
| 234 | complicated. Say that ``SpecialSquare`` and ``OtherSpecialSquare`` derive |
| 235 | from ``Square``, and so ``ShapeKind`` becomes: |
| 236 | |
| 237 | .. code-block:: c++ |
| 238 | |
| 239 | enum ShapeKind { |
| 240 | SquareKind, |
| 241 | + SpecialSquareKind, |
| 242 | + OtherSpecialSquareKind, |
| 243 | CircleKind |
| 244 | } |
| 245 | |
| 246 | Then in ``Square``, we would need to modify the ``classof`` like so: |
| 247 | |
| 248 | .. code-block:: c++ |
| 249 | |
| 250 | static bool classof(const Square *) { return true; } |
| 251 | - static bool classof(const Shape *S) { |
| 252 | - return S->getKind() == SquareKind; |
| 253 | - } |
| 254 | + static bool classof(const Shape *S) { |
| 255 | + return S->getKind() >= SquareKind && |
| 256 | + S->getKind() <= OtherSpecialSquareKind; |
| 257 | + } |
| 258 | |
| 259 | The reason that we need to test a range like this instead of just equality |
| 260 | is that both ``SpecialSquare`` and ``OtherSpecialSquare`` "is-a" |
| 261 | ``Square``, and so ``classof`` needs to return ``true`` for them. |
| 262 | |
| 263 | This approach can be made to scale to arbitrarily deep hierarchies. The |
| 264 | trick is that you arrange the enum values so that they correspond to a |
| 265 | preorder traversal of the class hierarchy tree. With that arrangement, all |
| 266 | subclass tests can be done with two comparisons as shown above. If you just |
| 267 | list the class hierarchy like a list of bullet points, you'll get the |
| 268 | ordering right:: |
| 269 | |
| 270 | | Shape |
| 271 | | Square |
| 272 | | SpecialSquare |
| 273 | | OtherSpecialSquare |
| 274 | | Circle |
| 275 | |
| 276 | .. TODO:: |
| 277 | |
| 278 | Touch on some of the more advanced features, like ``isa_impl`` and |
| 279 | ``simplify_type``. However, those two need reference documentation in |
| 280 | the form of doxygen comments as well. We need the doxygen so that we can |
| 281 | say "for full details, see http://llvm.org/doxygen/..." |