OSNews

What scheme is that? Could you please provide a link? I strongly suspect not, since the scheme I have in mind would not be remotely source or binary compatible with the current API by any stretch of the imagination. While it would be wise to include a way to include a version number for applications to query for, it isn't required. In fact, those overly concerned with C++ purity may be unhappy with what I have in mind, but at least it is viable long-term (as in never having an expansion problem: if the C++ compiler ABI changes, that may affect it, depending on the level of C++ purity) Because it isn't exactly as "pure" of C++ by intent, I'm not certain everyone will go for it, but it wouldn't cause old binaries to break, and wouldn't need backwards compatible C++ classes in libs and system kits, either. One of the side-effects of building an application or libs this way is that it's likely to result in simpler and smaller patch files for upgrades, too.

Well now from what you've just said, I'm not certain if the scheme you are refering too is even slightly similiar to ours, but anyway.

An example: http://syllable.cvs.sourceforge.net/syllable/syllable/system/sys/ap...

Every "external" class in the API has an internal private class that holds all of the data members. The only data member in the external class is a pointer to the corresponding private class. The external class then uses the data members of it's private class, instead of having data members itself. E.g.:

class Foo::Private{
int a;
char z;
float f;
};

class Foo{
public:
Foo();
private:
Private *m;
};

Foo::Foo()
{
m = new Private();
m->a = 42;
m->z = 'b';
m->f = 1.0f;
}

We also reserve vtable slots in every "external" class to provide space if we ever wish to add additional virtual methods without increasing the vtable size.

These two things alone largely take care of the FBC problem. This scheme was designeds by Kurt and has been in use since the very first release of AtheOS, if I remember correctly.