Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows you to define "static COM objects". Static COM objects are COM objects that are stored in static fields. This avoids the need for a separate heap allocation for stateless COM objects. It also allows
const fn
initialization of static COM objects.A static COM object is not the same as a
ComObject<T>
stored in a static field.ComObject<T>
is a pointer, which owns 1 reference count, to an allocated COM object.StaticComObject<T>
directly contains the COM object's data, its reference count, and its vtable pointers.Just like
ComObject<T>
,StaticComObject<T>
allows you to cast it to any interface chain or interface pointer, and even to create aComObject<T>
that points to theStaticComObject<T>
. This is safe because creating theComObject<T>
increases the reference count of the static object; dropping theComObject<T>
decreases the reference count, but it will never reach zero so it will never be "freed" (which would be wrong).This feature is intended to support and simplify apps that need to define factory objects and other stateless objects. There is no need to heap-allocate these objects. This also simplifies their initialization because we simply never need to run any initialization logic at all, so we eliminate "order of initialization" bugs.