Top Content Up

5.1 Definition

Next

Building a component definition is always the same. For a given component, you need a struct object with the same name, but with the prefix _F_. So for the component loadfile, we have "struct _F_loadfile".

Here is an example:

#define _TLMP_foo
struct _F_foo {
	#define _F_foo_start(n) void n start()
	virtual _F_foo_start( );
	#define _F_foo_loop(n) void n loop(int count)
	virtual _F_foo_loop( )=0;
	#define _F_foo_end(n) void n end()
	virtual _F_foo_end( );
};

Building a component

the first define (_TLMP_foo) is a trick to help tlcc. If you fail to include the definition for a component, you will get a nice error message while compiling. tlcc insert a sequence like the following everytime you reference a compoment (use the call or obj tag):
#ifndef _TLMP_foo
	#error Component foo is unknown
#endif


The define _F_foo_start(n) may need some explanation. Everytime tlcc sees a "f" tag such as <f start> within a <call module>> or <obj class> scope, it combine the component (or class) name with the "f" tag parameter and use it as a macro. It passes a single argument to the macro: The name of a new class (The "n" parameter in the define _F_foo_start).

So the <call> sequence is translated into:

  • A new class definition, derived from _F_foo.
  • For every "f" tag, a member function is defined, overriding the original _F_foo member function. Using the _F_foo_start() macro for example, we know the new function will have the exact same definition as the parent class.
  • An object of the new class is created.
  • The component is called. The first parameter passed is the newly created object.
Top Content Up

Next
Table of content
One big HTML document