Re: Ideas on the future of Quesa.

[James W. W. <ja...@wr...>]

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.

>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.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>