Re: class registration/unregistration

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

On Monday, January 31, 2005, at 06:43  pm, James W. Walker wrote:

> Did you test with Q3_MEMORY_DEBUG on?  For me, the block trailer test 
> in E3Memory_Free failed.

No I have never touched Q3_MEMORY_DEBUG unless it is turned on in the 
normal debugging version.



>>>  Before your changes, Quesa never used 
>>> kQ3XMethodTypeObjectClassRegister, correct?  Shouldn't it use 
>>> kQ3XMethodTypeObjectClassUnregister as well?
>>
>> Perhaps I should have invented a new name rather than use one I knew 
>> to be free and unlikely to be used.
>>
>> A new method is needed because I want to use constructors to fill in 
>> method pointers for each class's info
>> record and all its parent class info. This should work very well but 
>> there is the problem of what to do when
>> an external class is registered by an application/renderer. What is 
>> then needed is for each class to have a
>> method which will call call new(std::nothrow) for its own class to 
>> make the external class's info record and
>> fill in all the methods using the new class's meta-handler, its own 
>> meta handler and its ancestor class's
>> meta-handlers until it gets a non nil value returned (or it runs out 
>> of ancestors). The facility of adding new
>> method pointers for non built in classes is not something we are ever 
>> likely to allow (QD3D did not allow
>> it and up to now even built in classes could not do it, though I 
>> think built in QD3D classes probably did).
>> Anyway, as we are just setting up pointers to functions and not 
>> allocating memory then there is no need
>> to do anything similar on unregistering. Indeed if we were to need 
>> this we would need to have a virtual
>> destructor, and the use of virtual functions has been ruled out so 
>> this is a no-no.
>>
>> Shall I invent a new name? How about kQ3XMethodTypeNewClassInfo?
>
> Maybe I am misunderstanding, but are you saying that an external class 
> would need to call operator new?  I think it would be bad to make any 
> assumption about how an external class allocates memory.  A class 
> implemented in a plug-in may be built with a different compiler and 
> run-time library.

No when the external class registers itself in the normal way, Quesa 
now needs to call new for the parent class info (or the parent
of the parent class etc back as far as a built in class which has an 
operator new). Note this is the class INFO, not an instance.
The new method does just this, passing in a couple of parameters, the 
meta handler and the actual parent class.

> I think this discussion should be moved to the public list, in case 
> anyone else has ideas.

Done.



Roger.

P.S. have saved 40k on the size of the release version of Quesa just by 
optimising a couple of macros when
Q3DEBUG makes Q3ASSERT do nothing. In this condition we do not need to 
save a temporary boolean
to hold the result of the test. The compiler generates extra code to 
save and restore registers for the
temporary. This does not get optimised away under CW 8.3, maybe it 
would with other compilers but there
is no harm in the new version. I expect it saves some execution time 
too.