Re: Ideas on the future of Quesa.

[Roger H. <rog...@mi...>]

On Tuesday, November 30, 2004, at 06:32  pm, James W. Walker wrote:

> Roger Holmes <rog...@mi...> wrote:
>
>> Ok so I was trying to gather your comments on virtual functions and 
>> you
>> seem to be dead set against them, but so was I at first. If you are
>> still
>> against them after reading this I will drop the idea. 0xDEADD0D0.
>>
>> But first inheritance. The instance data of a Quesa sub class is 
>> ideally
>> held in memory just after the base class's data. That way we can
>> allocate
>> just one block of data for all the instance data of a leaf class and
>> all its
>> base classes in one go, and we do not have to follow a chain of 
>> pointers
>> to find a particular sub class's instance data. This has shown a great
>> performance boost for processing and rendering of complex documents.
>> Of course we could do this with structs, by defining a first data 
>> member
>> to be the base class's instance data, but we do want to keep the data
>> private to a class and not have it messed about with by derived 
>> classes,
>> so to have a struct/class inherit all the data members from its base
>> class
>> privately is the only way to do this properly. Of course this also
>> inherits
>> the methods but if we don't want this then we just don't define any
>> methods.
>
> If you can speed up access to instance data without compromising 
> extensibility, that would be great.

Traditional extensions would get their instance data allocated after 
the data of the class they
inherit from by just adding the requested number of bytes to the sizeof 
the base class instance.


>
>> Virtual methods. The other big speed up I made in Quesa was by
>> implementing in C the closest thing I could to a C++ VTable. I could
>> bring this code forward into cvs Quesa but the thought of allowing the
>> C++ compiler to do it for me is appealing as it is simper, less prone 
>> to
>> error and more readable. Where there is now a hash table look up for
>> a method we would instead use a virtual method. This would not of
>> course affect the API, just as the API does not expose the existing
>> functionality. There is of course the problem of extensibility. It 
>> might
>> be possible to have an extension class which would get called for
>> extension classes and would then vector off in the existing way.
>> However, apart from renderers, how many of us have actually
>> extended Quesa, I have but I would be very happy to modify my
>> extension into clean C++ classes linked into Quesa instead of the
>> horrid mess of meta handlers and multiple functions which
>> were necessary with the closed source library QD3D.
>>
>> So have I talked you around?
>
> I'm still concerned about extensibility.  I've written lots of custom 
> elements and have plans for custom renderers.  With the current setup, 
> it is theoretically possible for a plugin renderer to derive from the 
> built-in IR, using Q3XObjectClass_GetMethod to get an IR function 
> pointer.  If the IR methods were C++ methods, they would have a 
> different function signature.
>

I have written a plug in renderer, custom elements and custom groups. I 
would not break any of these otherwise
the Microspot products derived from 3D World would stop working. I 
don't think Apple ever got around to opening
up the API for custom geometries or anything other than the three I 
have used.

We could have an old style wrapper for the new style virtual methods 
but that makes the whole
thing pretty pointless.