Boost logo

Boost :

From: Hamish Mackenzie (boost_at_[hidden])
Date: 2001-04-04 14:13:29

Clearly there are many types of interface (some of which are for users, some
like RPC, SOAP, COM, CORBA are not). Also if you think back to ooa/ood 101
every class has an interface. I don't think GUI's can be considered in
isolation, especially as they are normally built on top of one of the others.

If we do we run the risk of including things specific to our interpretation
of what a GUI should be. Should the coordinate system be integers or floats,
2d or 3d as in the case of an user interface built on OpenGL (I like to call
them GLUIs)? Does having coordinates make sense at all (eg. for a CLI)?

I think instead we should consider all types of interface first and try to
determine areas of commonality that can be exploited. Then meta data can be
added to allow the addition of features which are specific to a particular
type of interface.

Both CORBA and COM use IDL files to describe interfaces. Also in
Java where reflection is used to describe interfaces. If we can develop a
similar system of describing our internal interfaces independent of what
additional interfaces are going to wrap around them then not only could
people write cross platform code but the same could be used for all the
different sorts of interface.

We need to be able to...
* Enumerate interfaces in a module.
* Enumerate members of an interface.
* Enumerate arguments of a function.
* Set/get member variables generically.
* Call member functions generically.
* Attach arbitrary meta data to any part of the interface.

I see three possible approaches
1. Use CORBA/COM style IDL
2. Use templates to describe interfaces
3. Build new language features to support reflection at compile time

1. CORBA/COM style IDL
I personally don't like this option as it means coding in a language other
than C++ and that kind of defeats the purpose of using C++. I am not
existing IDL formats allow what could be described as arbitrary meta data.
So we would have to work that out still.

2. Templates
I have not tried this option out extensively but I have uploaded a very
small/incomplete sample here
Note: This is also another example of the "type vector" I mentioned in an
earlier post in use. I am hoping to flesh out some more documentation for it
when I have time.

3. Compile Time Reflection
If C++ had reflection life would be much simpler. However would we want the
performance hit and memory overhead at runtime. My guess is no. Instead a
form of compile time reflection built on templates would be better. Then
runtime reflection could be added on top as a set of classes that expose
parts of the compile time reflection data at run time.

In fact option 2 is pretty close to that already. However it would be nice
to keep the existing syntax of class definitions to define the interfaces.

The problem doing this without extending the language is that there is no way
to enumerate anything (classes, members of a class or arguments of a
function). Given a class you can't even loop through the members and write
them to std::cout.
I have tried writing a small preprocessor to write out meta data about
classes found in "special" header files (ie with no macros or templates).
Unfortunately I have accidently deleted the preprocessor and the backup is in
storage at my inlaws roof space. But thats ok as it was not very good anyway
as it was just meant as a proof of concept. I have a sample of what it does
and have put it here

Basically the canvas_app.h was generated from the canvas_app.h2 file. A
bunch of member classes which describe the members are added. It also
creates names.h which provides string the constants needed. You can then
enumerate member functions and variables and set and get. The oot_defs.h file
has some basic access helpers.

The program I was writing used the wxWindows library and call_dialog.h shows
how I was able to create simple dialogs based on the meta data stored about
members. Unfortunately I have since ported the app to OpenGL and dropped all
the wxWindows code.

Both options 2 and 3 could be fleshed out to include support advanced
features such as inheritance and template members.

It would also be possible (though not easy) to create a set of classes to
generate a COM, CORBA or SOAP interface wrapper.

Finally one nice side effect of all this is that it could be used for the
basis for a persistence library too.

Hamish Mackenzie

Boost list run by bdawes at, gregod at, cpdaniel at, john at