Hi Paul,

Thanks for the explicit example.  I see, so we use some naming convention
and take advantage of the C pre-processor to determine the function at
compile time.  It seems that this approach is very maintainable and much
better than keeping the function pointers.  (Hey, can I then actually
write object-oriented model using only C from scratch easily? :) I don't
know about objective-C.)

On another slightly different subject, I think last time it was suggested
in C object creation, one approach is to create the inner objects before
the outer objects.  However, assuming arbitrarily complex and nested mix
of VALUE's and C data in the struct's, I don't think this approach is
foolproof.  The problem is if when creating the inner objects the gc 
actually gets invoked, these inner objects are swept away.  I don't know
whether the double initialization technique is really foolproof.

Regards,

Bill
==============================================================================
Paul Brannan <pbrannan / atdesk.com> wrote:
> What I'm suggesting is something like this:

>   /* We define a naming convention for a function func in class Klass:
>    *   Klass_func
>    * We also require that a class Klass with base class Base will have a
>    * macro:
>    *   Klass_Base
>    * so at compile-time we can know who the base class is.
>    */
>   
>   #define BASE_OF(klass) klass##_Base
>   #define CALL_BASE(klass, func) \
>     BOOST_PP_CAT( \
>         BOOST_PP_CAT(BASE_OF(klass), _), \
>         func)
>   #define CAST_TO_BASE(klass, x) \
>     (BASE_OF(klass) *)(x)
>   #define CALL_BASE_MARK(klass, x) \
>     (CALL_BASE(klass, mark(((BASE_OF(klass) *)x))))