[openbeosnetteam] Re: PPP: dial-on-demand

  • From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
  • To: <openbeosnetteam@xxxxxxxxxxxxx>
  • Date: Sat, 5 Jul 2003 14:14:51 +0200

> As I already tried to explain, C++ in the kernel is *not* usable that
> way now until we have real shared libraries, at least not if you want
> to implement the net stack as a module.
> You can't export a C++ API in modules, and therefore, you can't inherit
> from a class defined in a module - C++ can currently only be used per
> module, but not really inter-modular :)

That is clear to me and this is the reason why I want to use a static
library that contains all classes.
It, of course, makes changes in the core impossible without recompiling all
other modules, but as we will be the only ones who develop such modules it
is no problem.
At least, it will work until we get shared libraries in the kernel. Then, we
can change the core module (e.g.: eliminate bugs) and all modules will
profit.

> Furthermore, with a C API you can implement your modules in both, C and
> C++ - with a C++ API you force all add-ons to be written in C++, and
> that's certainly something I don't want to do at this point.

The alternative would be that we use a C API to access all module functions
and these functions call the C++ implementation.
Additionally we have some C++ wrapper classes, so that all modules are
implemented in C++, but they do not have to be.
This might be the best solution.
For my ppp_interface_manager module I plan to export a C-like API that gets
C++ interface objects as parameters (can we call it C then?).
The reason for this is that there should be only one interface manager. If
it is a class it can be instantiated by everyone.With a trick we could use a
friend function that allows this, but a function with the same name would
allow it in every other module, too.
For instance, the interface manager talks to our netstack to add ppp
interfaces. It maintains a list of already used interfaces. If now someone
instantiates a Manager object we get in trouble because it will try to
allocate "ppp0" which is already in use by the Manager object in our
interface manager module. It will fail.
Thus, there should be no C++ objects representing the real interface. C
wrappers are much better. Additionally we can add C++ access objects for the
C module APIs.
Is that understandable? :)
Here is an example:

// manager.h
typedef struct manager_info {
void (*add_protocol) (Protocol *object); // Protocol is an object, but
add_protocol points to some C function
} manager_info;

// manager.c (the real module)

class Manager {
void AddProtocol(Protocol *object);
};

static Manager core;

void add_protocol(Protocol *object)
{
core.AddProtocol(object);
}

manager_info info = { &add_protocol };

No doubt, this is more work, but nobody will ever create a Module object
(except the module that implements the API).

Or do you think it is better to have a pointer to the object in the
module_info and hope that nobody tries to create one in his own module?

Waldemar


Other related posts: