W
Wolfgang Draxinger
Component systems with C++ are quite some challenge. Microsoft
tried it with COM and it was not the big hit, there is CORBA,
which isn't focused on C++ but only supports a limited set of
value types (depending on the actual implementation) and DCop of
the KDE project, which is more sophisticated but still has to
deal with some limitations.
Some people have given up on it, e.g. Microsoft, which has
developed .net. Yesterday I took a look at the OSS variant Mono.
But in all cases the main problem of component systems that are
to be integrated with C++ is, that it's quite difficult to
implicitly describe the so called metadata of a C++ type.
Just as an example take this piece of senseless but pathologic
code
| #include <vector>
|
|
| class foo_class;
|
| typedef std::vector<foo_class> foo_vector;
|
| class foo_class
| {
| public:
| foo_class(int i)
| {
| }
| foo_class(foo_vector bar)
| {
| foo_bar=bar;
| }
| private:
| foo_vector foo_bar;
| };
|
| int foo()
| {
| foo_vector T;
| for(int i=0; i<10; i++)
| {
| T.push_back(foo_class(i));
| }
| }
Running this through gccxml gives an impressive insight of what
the C++ compiler is achieving here. I don't want to post it, but
it shows - not surprisingly - a complete implementation of a
vector class for the foo_class type. Now there is the question:
If I would expose this as a component would it make sense to
expose the whole new type foo_vector?
Before you awnser "YES" just take a look at languages like
Python: Those have a generic list type (sharing the properties
of vectors) which can hold any other type of object, and in
which every any element can be of a different type.
If you would take this sort of approach, a component system must
provide a set of builtin types, that are common to most
languages. I think the types provided by the STL plus the C++
native types would be sufficient, since any other sensefull type
can and should be built by these (only for strings I wouldn't
use the original STL std::string but a similair type that can
handle I18N and Unicode). But still there is one problem. How
can you define a generic type in C++ so that it is easly
exported?
The approach of .net is the same as in script languages:
Containers can accept any type, as they are on demand adopting
the the needs.
And here comes my problem: In the last months I was trying to
create my own lightweight and portable component system.
Component systems that already exist either need a properly
installed infreastructure or they aren't very portable. The idea
that I have in mind is, to add a very small virtual machince
or/and some gode generation for specific architectures that
glues components. But I have one big problem: How can I
interface coplex types? So far the best thing I has was a custom
written reflection interface that would be linked by my
component system's dynamic linker. However those interfaces
would only be some remote control into the other component. This
is fine as long it is not neccesary to access any data from the
other side, but as soom you need to that I'm in trouble. So far
the only thing I can do it pass the pointer and hold thumbs that
the binary representation is compatible.
Ok, in one sentence: How can I deal with arbitrary types in C++
and pass their metadata information to the component system's
linker (I already have developed a own binary format derived
from ELF, but with the addition, that it can hold arbitrary
metadata and an dynamic linker, but there still remains stuff to
do). And I want to it being as KISSed (keep it simple stupid) as
possible, i.e. as few compiler dependencies as possible, etc.
Any ideas? Anyone? Or am I completely nuts?
Wolfgang Draxinger
--
tried it with COM and it was not the big hit, there is CORBA,
which isn't focused on C++ but only supports a limited set of
value types (depending on the actual implementation) and DCop of
the KDE project, which is more sophisticated but still has to
deal with some limitations.
Some people have given up on it, e.g. Microsoft, which has
developed .net. Yesterday I took a look at the OSS variant Mono.
But in all cases the main problem of component systems that are
to be integrated with C++ is, that it's quite difficult to
implicitly describe the so called metadata of a C++ type.
Just as an example take this piece of senseless but pathologic
code
| #include <vector>
|
|
| class foo_class;
|
| typedef std::vector<foo_class> foo_vector;
|
| class foo_class
| {
| public:
| foo_class(int i)
| {
| }
| foo_class(foo_vector bar)
| {
| foo_bar=bar;
| }
| private:
| foo_vector foo_bar;
| };
|
| int foo()
| {
| foo_vector T;
| for(int i=0; i<10; i++)
| {
| T.push_back(foo_class(i));
| }
| }
Running this through gccxml gives an impressive insight of what
the C++ compiler is achieving here. I don't want to post it, but
it shows - not surprisingly - a complete implementation of a
vector class for the foo_class type. Now there is the question:
If I would expose this as a component would it make sense to
expose the whole new type foo_vector?
Before you awnser "YES" just take a look at languages like
Python: Those have a generic list type (sharing the properties
of vectors) which can hold any other type of object, and in
which every any element can be of a different type.
If you would take this sort of approach, a component system must
provide a set of builtin types, that are common to most
languages. I think the types provided by the STL plus the C++
native types would be sufficient, since any other sensefull type
can and should be built by these (only for strings I wouldn't
use the original STL std::string but a similair type that can
handle I18N and Unicode). But still there is one problem. How
can you define a generic type in C++ so that it is easly
exported?
The approach of .net is the same as in script languages:
Containers can accept any type, as they are on demand adopting
the the needs.
And here comes my problem: In the last months I was trying to
create my own lightweight and portable component system.
Component systems that already exist either need a properly
installed infreastructure or they aren't very portable. The idea
that I have in mind is, to add a very small virtual machince
or/and some gode generation for specific architectures that
glues components. But I have one big problem: How can I
interface coplex types? So far the best thing I has was a custom
written reflection interface that would be linked by my
component system's dynamic linker. However those interfaces
would only be some remote control into the other component. This
is fine as long it is not neccesary to access any data from the
other side, but as soom you need to that I'm in trouble. So far
the only thing I can do it pass the pointer and hold thumbs that
the binary representation is compatible.
Ok, in one sentence: How can I deal with arbitrary types in C++
and pass their metadata information to the component system's
linker (I already have developed a own binary format derived
from ELF, but with the addition, that it can hold arbitrary
metadata and an dynamic linker, but there still remains stuff to
do). And I want to it being as KISSed (keep it simple stupid) as
possible, i.e. as few compiler dependencies as possible, etc.
Any ideas? Anyone? Or am I completely nuts?
Wolfgang Draxinger
--