Changes in / [70284830:f6cc2096]

File:

• doc/proposals/virtual.txt (modified) (3 diffs)

doc/proposals/virtual.txt

@@ -147 +147 @@
 
 This gives us an important extra feature, runtime checking of the parent-child
-relationship with a C++ dynamic_cast like operation. Allowing checked
-conversions from trait references to more particular references, which works
-if the underlying type is, or is a child of, the new trait type.
+relationship with virtual cast, where a pointer (and maybe a reference) to
+a virtual type can be cast to another virtual cast. However the cast is
+dynamicly check and only occurs if the underlying type is a child of the type
+being cast to. Otherwise null is returned.
+
+(virtual TYPE)EXPR
+
+As an extention, the TYPE may be ommitted if it can be determained from
+context, for instance if the cast occurs on the right hand side of an
+assignment.
 
 Extension: Multiple Parents
@@ -251 +258 @@
 autogenerated and often unique.
 
+It may be worth looking into a way to force the vtable pointer to be in a
+particular location, which would save the storage to store the offset and
+maybe the offset operation itself (offset = 0). However it may not be worth
+introducing a new language feature for.
+As of writing, exceptions actually use this system.
+
 
 Keyword Usage:
@@ -276 +289 @@
 Calling free on a trait reference will free the memory for the object. It will
 leave the vtables alone, as those are (always?) statically allocated.
+
+
+Special Traits:
+
+trait is_virtual_parent(dtype parent, dtype child) { ... };
+
+There are others but I believe this one to be the most important. The trait
+holds if the parent type is a strict virtual ancestor (any number of levels)
+of child. It will have to exist at least internally to check for upcasts and
+it can also be used to optimize virtual casts into upcasts. Or a null value or
+error if the cast would never succeed. Exporting it to a special trait allows
+users to express that requirement in their own polymorphic code.
+
+
+Implementation:
+
+Before we can generate any of the nessasary code, the compiler has to get some
+additional information about the code that it currently does not collect.
+
+First it should establish all child->parent links so that it may travel up the
+hierarchy to grab the nessasary information, and create the actual parent
+pointers in the strict virtual tables. It should also maintain the connections
+between the virtual type (structure or trait), the vtable type and the vtable
+instance (or default instance for relaxed virtual if multiple are allowed). To
+this end a sub-node should be created with the nessasary pointers. Traits and
+structs with virtual can create an instance and store all the nessasary data.
+
+With the hierarchy in place it can generate the vtable type for each type,
+it will generally have a function pointer field for each type assertion in
+some consistant order. Strict virtual will also have a pointer to the parent's
+vtable and intrusive vtables will also have the offset to recover the original
+pointer. Sized types will also carry the size.
+
+Wheither the vtable is intrusive or not should also be save so that the trait
+object/reference/pointer knows if it has to store 1 or 2 pointers. A wrapper
+function will have to be generated for each type assertion so that they may
+be called on the trait type, these can probably be inlined.
+
+The virtual parameter will also have to be marked (implicately or explicately)
+until code generation so that the wrapper functions know where to go to get
+the vtable for the function look up. That could probably be added as a
+storageclass, although one that is only valid on type assertions.
+
+The generated vtable will than have to have a vtable instance created and
+filled with all the approprate values. Stricter matching may have to be used
+to ensure that the functions used are stable. It will also have to use
+".gnu.linkonce" or equilant to ensure only one copy exists in the final code
+base.