Changeset e1e4aa9 for doc/proposals
- Timestamp:
- Jul 20, 2017, 4:04:11 PM (7 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 21a5dde1
- Parents:
- c72f9fd
- File:
-
- 1 edited
-
doc/proposals/virtual.txt (modified) (13 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/proposals/virtual.txt
rc72f9fd re1e4aa9 66 66 67 67 The keyword trait is optional (by the same rules as the struct keyword). This 68 is not currently sup orted in CFA and the lookup is not possible to implement68 is not currently supported in CFA and the lookup is not possible to implement 69 69 statically. Therefore we need to add a new feature to handle having dynamic 70 70 lookups like this. … … 75 75 76 76 For instance specifying that the drawable trait reference looks up the type 77 of the first argument to find the implemen ation would be :77 of the first argument to find the implementation would be : 78 78 79 79 trait drawable(otype T) { … … 84 84 trait and single generic parameter on the function). In more complex cases it 85 85 would have to be explicitly given, or a strong convention would have to be 86 enforced (e.g. implementation of trait functions is always drawn from the 86 enforced (e.g. implementation of trait functions is always drawn from the 87 87 first polymorphic parameter). 88 88 89 89 Once a function in a trait has been marked as virtual it defines a new 90 90 function that takes in that trait's reference and then dynamically calls the 91 underlying type implemen ation. Hence a trait reference becomes a kind of91 underlying type implementation. Hence a trait reference becomes a kind of 92 92 abstract type, cannot be directly instantiated but can still be used. 93 93 … … 100 100 Extension: Multi-parameter Virtual Traits: 101 101 102 This implementation can be exten ted to traits with multiple parameters if102 This implementation can be extended to traits with multiple parameters if 103 103 one is called out as being the virtual trait. For example : 104 104 … … 122 122 123 123 To allow down casting strict virtual requires that all traits and structures 124 involved be org inized into a tree. Each trait or struct must have a unique124 involved be organized into a tree. Each trait or struct must have a unique 125 125 position on this tree (no multiple inheritance). 126 126 … … 148 148 This gives us an important extra feature, runtime checking of the parent-child 149 149 relationship with a C++ dynamic_cast like operation. Allowing checked 150 conver tions from trait references to more particular references, which works150 conversions from trait references to more particular references, which works 151 151 if the underlying type is, or is a child of, the new trait type. 152 152 153 Exten tion: Multiple Parents153 Extension: Multiple Parents 154 154 155 155 Although each trait/struct must have a unique position on each tree, it could … … 161 161 The restriction being, the parents must come from different trees. This 162 162 object (and all of its children) can be cast to either tree. This is handled 163 by generating a sep erate vtable for each tree the structure is in.164 165 Exten tion: Multi-parameter Strict Virtual166 167 If a trait has multiple parameters th an one must be called out to be the one168 we generate sep erate vtables for, as in :163 by generating a separate vtable for each tree the structure is in. 164 165 Extension: Multi-parameter Strict Virtual 166 167 If a trait has multiple parameters then one must be called out to be the one 168 we generate separate vtables for, as in : 169 169 170 170 trait example(otype T, otype U) virtual(T) ... 171 171 172 This can generate a sep erate vtable for each U for which all the T+U173 implementations are provided. These are then sep erate nodes in the tree (or174 the root of different trees) as if each was created individually. Providing a 175 single unique instance of these nodes would be the most difficult aspect of 176 this extension, possibly intractable, though with sufficient hoisting and 172 This can generate a separate vtable for each U for which all the T+U 173 implementations are provided. These are then separate nodes in the tree (or 174 the root of different trees) as if each was created individually. Providing a 175 single unique instance of these nodes would be the most difficult aspect of 176 this extension, possibly intractable, though with sufficient hoisting and 177 177 link-once duplication it may be possible. 178 178 … … 188 188 }; 189 189 190 Exten tion: Structural Inheritance190 Extension: Structural Inheritance 191 191 192 192 Currently traits must be the internal nodes and structs the leaf nodes. 193 Structs could be made internal nodes as well, in which case the child structs 193 Structs could be made internal nodes as well, in which case the child structs 194 194 would likely structurally inherit the fields of their parents. 195 195 … … 201 201 Creation happens at compile time. Function pointers are found by using the 202 202 same best match rules as elsewhere (additional rules for defaults from the 203 parent may or may not be req ired). For strict virtual this must happen at the204 global scope and forbid ing static functions, to ensure that a single unique203 parent may or may not be required). For strict virtual this must happen at the 204 global scope and forbidding static functions, to ensure that a single unique 205 205 vtable is created. Similarly, there may have to be stricter matching rules 206 206 for the functions that go into the vtable, possibly requiring an exact match. … … 209 209 local functions being bound to a vtable could cause issues when they go out 210 210 of scope, however this should follow the lifetime rules most C programs 211 already follow implic ately.211 already follow implicitly. 212 212 213 213 Most vtables should be stored statically, the only exception being some of … … 222 222 stored along side it. 223 223 224 This allows for compat ability with existing structures (such as those imported224 This allows for compatibility with existing structures (such as those imported 225 225 from C) and is the default storage method unless a different one is given. 226 226 227 227 The other is by inlining the vtable pointer as "intrusive vtables". This adds 228 a field to the structure to the vtable. The trait reference th an has a single228 a field to the structure to the vtable. The trait reference then has a single 229 229 pointer to this field, the vtable includes an offset to find the beginning of 230 230 the structure again. … … 233 233 trait the vtable pointer in the trait reference can then become a single 234 234 pointer to the vtable field and use that to recover the original object 235 pointer as well as retri ve all operations.235 pointer as well as retrieve all operations. 236 236 237 237 trait drawable(otype T) { … … 248 248 (although they still must be called specially). The vtable field may just be 249 249 an opaque block of memory or it may allow user access to the vtable. If so 250 th an there should be some way to retrive the type of the vtable, which will be250 then there should be some way to retrieve the type of the vtable, which will be 251 251 autogenerated and often unique. 252 252
Note: See TracChangeset
for help on using the changeset viewer.
