Blogs and thoughts of cpgf library

Today I created a new todo task in the task system. The task is about to add a new type to GVariant to allow GVariant holds both variant data and meta type. Suddenly I had a new idea, why not to use function traits to allow the users to add arbitrary variant types to extend GVariant?

Pseudo C++ code:

// General function to create variant with built-in types
// same as how we do now
GVariant createVariant(...);
 
// The user may extend to add new variant type for FooClass
// The returned GVariant has a new variant type, such as vtFoo
GVariant createVariant(const FooClass & fooObject);

I felt excited about the new idea and almost wanted to add a new todo task for it. But then after a while, I realized the idea is completely wrong.

The reason is simple. GVariant must be platform independent and can be transferred across shared modules (DLLs).

That's how GVariant was designed for, similar as the VARIANT type in Windows Component Object Modal (COM). If we allow the users to extend GVariant with arbitrary variant types, we can't guarantee the extended type exists in another module (DLL), and we also can't guarantee the extended type has same size and layout in another module.

Though up to now cpgf is not tested in cross modules environment and it most likely can't work due to the C++ type cast on interfaces, crossing modules is our long term goal and we will definitely implement it one day in the future. So we have to take care about the crossing module ability in the very core component such as GVariant.

Because this is so important and I don't want to forget, I write down this blog to remind myself every time I review the blog.