library design

[Frank Fischer]

Hi,

I have a possibly stupid question about library design. Suppose you have a
module A with function fa_1(...), ..., fa_n(...) and two modules B1 and B2
with different implementations of some functions fb_1(...), ..., fb_m(...),
i.e. B1 and B2 share the same interface but have different implementations.
Module A should use either module B1 or module B2 to accomplish its task.
In C++ (or Java or whatever) I would propably create an abstract base class
B

class B {
public:
virtual void fb_1(...) = 0;
...
virtual void fb_m(...) = 0;
};

and derive two subclasses B1 and B2 from with different implementations.
Module A would be given a pointer two an instance of B

class A {
public:
void set_B(B* b);
...
};

and so on.

A direct translation to C could be a struct B holding function pointers,
i.e.

struct B {
void (*fb_1)(...);
...
void (*fb_m)(...);
};

and then create a struct with the function pointers pointing to the
functions of B1 or B2. The module functions of A would the call B1 or B2
with a construct like

struct B* b;
....
b->fb_1(b, ...);

So far so good, nothing new. With the above approach I there're many lines
in A like

a->b->fb_1(a->b, ...)

to call functions from B1 or B2. Furthermore, A and B both have contain a
large number of functions (so not only one function pointer). This seems
to be pretty ugly.

My question is: Are there better ways to organize a library where a module A
can use either functions from B1 or B2? All modules implementing the
interface B are known at compile-time, i.e. it should not be possible to
link against the library and create new implementations of B. But of
course, the library itself should be extensible in the sense that I want to
provide 3 or 4 implementations of B as part of the library in future. Is
there a way not to mimic the approach of C++ (with abstract base class and
so on) using structs with function pointers? How could the library and the
modules be organized to get the desired functionality? Or is the approach
described above *the* standard way to do this?

Thanks in advance!

Frank

 

[Joachim Schmitz]

Hi,

I have a possibly stupid question about library design. Suppose you
have a module A with function fa_1(...), ..., fa_n(...) and two
modules B1 and B2 with different implementations of some functions
fb_1(...), ..., fb_m(...), i.e. B1 and B2 share the same interface
but have different implementations. Module A should use either module
B1 or module B2 to accomplish its task. In C++ (or Java or whatever)
I would propably create an abstract base class B

class B {
public:
virtual void fb_1(...) = 0;
...
virtual void fb_m(...) = 0;
};

Wrong group C doesn't have classes or virtual functions, comp.lang.c++ is
down the hall

Bye, Jojo

 

[Ian Collins]

A direct translation to C could be a struct B holding function pointers,
i.e.

struct B {
void (*fb_1)(...);
...
void (*fb_m)(...);
};

and then create a struct with the function pointers pointing to the
functions of B1 or B2. The module functions of A would the call B1 or B2
with a construct like

struct B* b;
....
b->fb_1(b, ...);

So far so good, nothing new. With the above approach I there're many lines
in A like

a->b->fb_1(a->b, ...)

to call functions from B1 or B2. Furthermore, A and B both have contain a
large number of functions (so not only one function pointer). This seems
to be pretty ugly.

It can, but it's a common approach. Use of intermediate variables can
make the code a lot cleaner (use a B* variable for a->b).

 

[Ian Collins]

Wrong group C doesn't have classes or virtual functions, comp.lang.c++ is
down the hall

You should have read the full post before getting lathered up about C++.

 

[Joachim Schmitz]

You should have read the full post before getting lathered up about
C++.

Oh, yes, apologies to the OP!

Bye, Jojo

 

[Minimiscience]

I have a possibly stupid question about library design. Suppose you have a
module A with function fa_1(...), ..., fa_n(...) and two modules B1 and B2
with different implementations of some functions fb_1(...), ..., fb_m(...),
i.e. B1 and B2 share the same interface but have different implementations.
Module A should use either module B1 or module B2 to accomplish its task.
In C++ (or Java or whatever) I would propably create an abstract base class
B ....
My question is: Are there better ways to organize a library where a module A
can use either functions from B1 or B2?

Is the choice of using B1 or B2 being made at runtime or compile time? If it's
at compile time, A can be written without regard for which implementation is
used (the interfaces are *exactly* the same, correct?), and the desired B
module can then be linked with A and the rest of the code when the program is
compiled. I don't know of any compilers that would have a problem with this.

On the other hand, if the choice is indeed being made at run-time, then your
solution is the only really viable one.

I hope this helps,
-- Minimiscience