FAQ

The FAQ and Dos/Don'ts of runtime custom types

1. Try to use the macros when you can. They exist to help you, but also wrap a lot of the inner functionality for you.
2. You cannot (safely) make abstract or interface types. This is because handling the allocation and creation of vtables is significantly nontrivial.
3. You cannot make overloaded methods. This includes C++ methods that would overload with declared C# methods. Instead, just don't make them overloaded methods
4. You cannot make virtual C++ methods. This is because doing so would insert a vtable into your type and ruin the alignment. The alignment is critically important because it allows your custom type to actually be a custom type.
5. Interfaces must be implemented in full. This includes cases where an inherited interface would normally have a C# method that would occupy two distinct vtable slots. Instead, you must implement both of these slots yourself. You can simply have one of the calls forward to the other, however, so this is quite a trivial fix.
6. Make sure your C++ fields are after your C# fields, generally speaking.
7. Try to avoid inheriting custom types in general, but if you do, make sure you use the correct macros for doing so.
8. Try to avoid inheriting custom types and ALSO adding your own C# fields.
9. Try to avoid using C# fields.
10. C# static fields do not work, don't try. (This is because of how static fields cause very problematic issues on liveness calculations)
11. C++ static fields work, but are not GC safe. Consider a SafePtr, or a form of gc-aware allocation.
12. Try to avoid making value types (why do you need to?)
13. All C# defined fields in a custom type are GC safe, fields that are not C# fields are not GC safe.
14. Remember to call the base constructors on your inherited types (they are NOT implicitly called in your ctor).

There will be more