Changeset 1b94115
- Timestamp:
- Dec 13, 2018, 2:59:13 PM (6 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, no_list, persistent-indexer, pthread-emulation, qualifiedEnum
- Children:
- ff1efc10
- Parents:
- 0765121
- File:
-
- 1 edited
-
doc/proposals/vtable.md (modified) (13 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/proposals/vtable.md
r0765121 r1b94115 3 3 4 4 This is an adaptation of the earlier virtual proposal, updating it with new 5 ideas, reframing it and laying out more design decisions. 5 ideas, re-framing it and laying out more design decisions. It should 6 eventually replace the earlier proposal, but not all features and syntax have 7 been converted to the new design. 6 8 7 9 The basic concept of a virtual table (vtable) is the same here as in most 8 10 other languages. They will mostly contain function pointers although they 9 11 should be able to store anything that goes into a trait. 10 11 This should replace the virtual proposal, although all not all features have12 been converted to the new design.13 12 14 13 Trait Instances … … 39 38 combine(obj, 5); 40 39 40 As with `struct` (and `union` and `enum`), `trait` might be optional when 41 using the trait as a type name. A trait may be used in assertion list as 42 before. 43 41 44 Internally a trait object is a pair of pointers. One to an underlying object 42 45 and the other to the vtable. All calls on an trait are implemented by looking … … 44 47 remaining arguments to it. 45 48 46 Trait objects can be copied and moved by copying and moving the pointers. 47 They should also be able to own or borrow the underlying object. 49 Trait objects can be moved by moving the pointers. Almost all other operations 50 require some functions to be implemented on the underlying type. Depending on 51 what is in the virtual table a trait type could be a dtype or otype. 48 52 49 53 Hierarchy … … 56 60 tree. 57 61 58 The hiera chy would be a tree of types, of traits and structs. Currently we do62 The hierarchy would be a tree of types, of traits and structs. Currently we do 59 63 not support structural extension, so traits form the internal nodes and 60 64 structures the leaf nodes. … … 62 66 The syntax is undecided but it will include a clause like `virtual (PARENT)` 63 67 on trait and struct definitions. It marks out all types in a hierarchy. 64 PARENT may be omitted, if it is this type is the root of a hiera chy. Otherwise68 PARENT may be omitted, if it is this type is the root of a hierarchy. Otherwise 65 69 it is the name of the type that is this type's parent in the hierarchy. 66 70 … … 73 77 from a parent type to a child type are conditional, they check to make sure 74 78 the underlying instance is an instance of the child type, or an instance of 75 one of its children. The type then is recoverable at run time.79 one of its children. The type then is recoverable at run-time. 76 80 77 81 As with regular trait objects, calling a function on a trait object will cause 78 a look up on the the virtual table. The casting rules make sure anything that82 a look-up on the the virtual table. The casting rules make sure anything that 79 83 can be cast to a trait type will have all the function implementations for 80 84 that trait. 81 85 82 Converting from a concrete type (structures at the edge of the hier chy) to86 Converting from a concrete type (structures at the edge of the hierarchy) to 83 87 an abstract type works the same as with normal trait objects, the underlying 84 object is packaged with a virt al table pointer. Converting back to an abstract88 object is packaged with a virtual table pointer. Converting back to an abstract 85 89 type requires confirming the underlying type matches, but then simply extracts 86 90 the pointer to it. … … 92 96 it is the trait object could be a single pointer. 93 97 94 It is triv al to do if the field with the virtual table pointer is fixed.98 It is trivial to do if the field with the virtual table pointer is fixed. 95 99 Otherwise some trickery with pointing to the field and storing the offset in 96 100 the virtual table to recover the main object would have to be used. … … 114 118 115 119 The main thing CFA would need to do it this way is some single point where 116 the type declaration, including the functions that sati fy the trait, are120 the type declaration, including the functions that satisfy the trait, are 117 121 all defined. Currently there are many points where this can happen, not all 118 122 of them will have the same definitions and no way to select one over the … … 122 126 time and a single vtable created for each type at compilation time. 123 127 124 ### Explic ateResolution Points:125 Slightly looser than the above, there are explic atepoints where the vtables128 ### Explicit Resolution Points: 129 Slightly looser than the above, there are explicit points where the vtables 126 130 are resolved, but there is no limit on the number of resolution points that 127 131 might be provided. Each time a object is bound to a trait, one of the 128 resolutions is selected. This might be the most flex able option.132 resolutions is selected. This might be the most flexible option. 129 133 130 134 An syntax would have to be provided as above. There may also be the option 131 135 to name resolution points so that you can choose between them. This also 132 could come with the ab lity to forward declare them.136 could come with the ability to forward declare them. 133 137 134 138 Especially if they are not named, these resolution points should be able to … … 141 145 its own resolution. Syntax-wise this is the simplest as it should be able 142 146 to use just the existing declarations and the conversion to trait object. 143 It also is very close to the current polymorphic re olution rules.147 It also is very close to the current polymorphic resolution rules. 144 148 145 This works as the explic ateresolution points except the resolution points146 are implic ateand their would be no selection of which resolution to use. The149 This works as the explicit resolution points except the resolution points 150 are implicit and their would be no selection of which resolution to use. The 147 151 closest (current) resolution is always selected. 148 152 149 This could easily lead to an explosi tion of vtables as it has the most fine153 This could easily lead to an explosion of vtables as it has the most fine 150 154 grained resolution the number of bindings in a single scope (that produces 151 155 the same binding) could be quite high. Merging identical vtables might help … … 156 160 157 161 Vtables interact badly with the thunk issue. Conceptually vtables are static 158 like type/function data they carry, as those deci tions are made by the162 like type/function data they carry, as those decisions are made by the 159 163 resolver at compile time. 160 164 161 165 Stack allocated functions interact badly with this because they are not 162 static. There are se rveral ways to try to resolve this, however without a166 static. There are several ways to try to resolve this, however without a 163 167 general solution most can only buy time. 164 168 … … 168 172 169 173 Dynamically allocated vtables introduces memory management overhead and 170 requires some way to different ate between dynamic and statically allocated174 requires some way to differentiate between dynamic and statically allocated 171 175 tables. The stale function pointer problem continues unless those becomes 172 176 dynamically allocated as well which gives us the same costs again. … … 175 179 is now the limiting factor but it should be effectively the same as the 176 180 shortest lifetime of a function assigned to it. However this still limits the 177 lifetime "implic ately" and returns to the original problem with thunks.181 lifetime "implicitly" and returns to the original problem with thunks.
Note: See TracChangeset
for help on using the changeset viewer.
