Re: [Subhandler-devel] Some ideas for architecture

[Julio S. <jsa...@us...>]

El mar, 21-10-2003 a las 22:04, Laurent Pinchart escribi=F3:

> What is a Subhandler_Object ? What kind of methods and/or properties will=
 it=20
> hold ?

It contains mostly artifacts of the class-system implementation.  Each
object instance contains a pointer to a class descriptor (actually it is
a singleton, just one instance per class) that contains internal data
(name of the class, a pointer to the superior class descriptor), maybe=20
class or static properties  and pointers to all methods, both class
methods and instance methods.  Because of limitations of static
initializers in C, some of this pointers cannot be initialized
(especially method inheritance I could not implement statically), so
classes have to be initialized.  The class descriptor, thus, contains a
flag that indicates whether the class has been initialized and a pointer
to the class initialization function.  So, the class descriptor for
Subhandler_Object contains:

  int           _initialized;
  void(*_init_class)();
  char *        name;
  _Descriptor(SUPCLASS) *       sup;
  void(*destroy)(CLASS *this);

Here, destroy is the only real method that is defined at this level and
is inherited or refined by other classes that add more fields here.

As far as properties go, at this level the only property defined is a
pointer to the class descriptor struct:

   _Descriptor(CLASS) *_class;

Then, instance and class method calls are made easier with the help of
the following macros:

#define _MCALL(object, method, ...) (object->_class->method(object, ##__VA_=
ARGS__))
#define _CCALL(class, method, ...) (_Class(class).method(&_Class(class), ##=
__VA_ARGS__))

I think the above use with __VA_ARGS__ is C99-compliant and does not
require GNU extensions. I would hate to have to define _MCALL, _MCALL1,
_MCALL2 and so on.
                                                                           =
  =20
Hope it will become clear later.  It seems confusing, but everything is
recipe-based and supported by macros, so you get the hang of it quickly.
Or so I hope.

There is a double indirection to get to the real method address, but I
am counting on the compiler optimization and I think that, anyway, the
overhead  will be dwarfed by the cost of the lack of inlining.

> Most OO-oriented frameworks written in plain C (Gtk+/Gnome comes to mind=20
> immediately) Don't use underscores in the name of the classes. Shouldn't =
we=20
> stick to the same rules (for letter of each work in uppercase for class=20
> names, without underscores, and lowercase with underscores for members an=
d=20
> functions).

I have no preference on that.  I am happy to change if it makes things
clearer.

> I have some trouble figuring exactly what you put in which class, but I=20
> suppose it will be clear when I'll have a look at the code.

Well, I am pretty much doing it as I go.  I think when I have the sample
I am doing I will be able to look back and see what makes sense where
and then write some sort of specification or guideline.

> I don't have more comments for now. I'm still reading docs about MPEG and=
=20
> subtitles.

Adrie Stolk has provided a few other links that are interesting in
themselves or that point to other efforts that are working on related
subtitle handling.  I will update the link page with them.

Regards,

Julio