Need to create a C lib - using C++ classes - is it possible

[Angus]

Hello

We have a lot of C++ code. And we need to now create a library which
can be used from C and C++. Given that we have a lot of C++ code
using classes how can we 'hide' the fact that it is C++ from C
compilers?

Can we have a C header file which uses the functionality of the C++
files and compile this into a lib file?

Can anyone give me some pointers as to how to get started?

A

[sebastian]

Just enclose the user code in the C linkage namespace, eg:

extern "C" {
// C code
}

[Ian Collins]

Angus wrote:

Hello

We have a lot of C++ code. And we need to now create a library which
can be used from C and C++. Given that we have a lot of C++ code
using classes how can we 'hide' the fact that it is C++ from C
compilers?

You will have to declare a C interface to the the library.

Can we have a C header file which uses the functionality of the C++
files and compile this into a lib file?

Only that subset of the code that's legal C. You would have something like:

#ifdef __cplusplus
extern "C" {
#endif

/* your POD types and function declarations go here */

#ifdef __cplusplus
}
#endif

The function definitions would be compiled as C++ as part of with your
C++ library.

--
Ian Collins.

[Ian Collins]

sebastian wrote:

Just enclose the user code in the C linkage namespace, eg:

extern "C" {
// C code
}

Not a lot of use if the code is C and compiled with a C compiler...

--
Ian Collins.

[Paavo Helde]

Ian Collins <ia******@hotmail.comkirjutas:

Angus wrote:

>Hello

We have a lot of C++ code. And we need to now create a library which
can be used from C and C++. Given that we have a lot of C++ code
using classes how can we 'hide' the fact that it is C++ from C
compilers?

You will have to declare a C interface to the the library.

>Can we have a C header file which uses the functionality of the C++
files and compile this into a lib file?

Only that subset of the code that's legal C. You would have something
like:

#ifdef __cplusplus
extern "C" {
#endif

/* your POD types and function declarations go here */

#ifdef __cplusplus
}
#endif

The function definitions would be compiled as C++ as part of with your
C++ library.

To OP: beware that the extern "C" functions are not allowed to leak any
exceptions - this is kind of natural as the calling C client will not
have any means to deal with them. I would define a couple of macros to
put in the beginning and end of each extern "C" function, which
essentially do "catch(...)" and convert the exceptions into corresponding
C error codes or into whatever appropriate.

hth
Paavo

[Chris Thomasson]

"Angus" <an*********@gmail.comwrote in message
news:3c**********************************@p25g2000 hsf.googlegroups.com...

Hello

We have a lot of C++ code. And we need to now create a library which
can be used from C and C++. Given that we have a lot of C++ code
using classes how can we 'hide' the fact that it is C++ from C
compilers?

Can we have a C header file which uses the functionality of the C++
files and compile this into a lib file?

Can anyone give me some pointers as to how to get started?

You can try something like this:

<pseudo-code sketch>
__________________________________________________ ______________
/* my_class.h
-------------------------------------------------------------*/
#ifndef MY_CLASS_H
#define MY_CLASS_H
#ifdef __cplusplus
# define EXTERN extern "C"
#else
# define EXTERN extern
#endif

typedef void* my_class_type;

EXTERN int my_class_create(my_class_type*)
EXTERN int my_class_destroy(my_class_type);
EXTERN int my_class_do_something(my_class_type);

#endif

/* my_class.hpp
-------------------------------------------------------------*/
#ifndef MY_CLASS_HPP
#define MY_CLASS_HPP

class my_class {
public:
my_class();
~my_class() throw();
void do_something();
};

#endif

/* my_class.cpp
-------------------------------------------------------------*/
#include "my_class.h"
#include "my_class.hpp"
#include <cstdio>
my_class::my_class() {
std::printf("(%p)->my_class::my_class()\n", (void*)this);
}
my_class::~my_class() throw() {
std::printf("(%p)->my_class::~my_class()\n", (void*)this);
}
void my_class::do_something() {
std::printf("(%p)->my_class::do_something()\n", (void*)this);
}

int my_class_create(my_class_type* _pcthis) {
try {
*_pcthis = new my_class;
} catch(...) {
return -1;
}
return 0;
}
int my_class_destroy(my_class_type _cthis) {
my_class* const _this = (my_class*)_cthis;
try {
delete _this;
} catch(...) {
return -1;
}
return 0;
}
int my_class_do_something(my_class_type _cthis) {
my_class* const _this = (my_class*)_cthis;
try {
_this->do_something();
} catch(...) {
return -1;
}
return 0;
}
__________________________________________________ ______________


Now you can use it from C like:
__________________________________________________ ______________
#include "my_class.h"
int main(void) {
my_class_type _this;
my_class_create(&_this);
my_class_do_something(_this);
my_class_destroy(_this);
return 0;
}

__________________________________________________ ______________


Any thoughts?

[Ian Collins]

Chris Thomasson wrote:

"Angus" <an*********@gmail.comwrote in message
news:3c**********************************@p25g2000 hsf.googlegroups.com...

>Hello

We have a lot of C++ code. And we need to now create a library which
can be used from C and C++. Given that we have a lot of C++ code
using classes how can we 'hide' the fact that it is C++ from C
compilers?

Can we have a C header file which uses the functionality of the C++
files and compile this into a lib file?

Can anyone give me some pointers as to how to get started?

You can try something like this:

<pseudo-code sketch>
__________________________________________________ ______________
/* my_class.h
-------------------------------------------------------------*/
#ifndef MY_CLASS_H
#define MY_CLASS_H
#ifdef __cplusplus
# define EXTERN extern "C"
#else
# define EXTERN extern
#endif

Why go to all that trouble when you can just write

#ifdef __cplusplus
extern "C" {
#endif

typedef struct my_class my_class_type;

int my_class_create(my_class_type**);
int my_class_destroy(my_class_type*);
int my_class_do_something(my_class_type*);

#ifdef __cplusplus
}
#endif

Then you don't have to mess about with casts in the C++ code.

--
Ian Collins.

[Angus]

On 24 May, 22:46, Ian Collins <[e-mail]:

Chris Thomasson wrote:

"Angus" <[e-mail] in message
news:3c**********************************@p25g2000 hsf.googlegroups.com...

Hello

We have a lot of C++ code. *And we need to now create a library which
can be used from C and C++. *Given that we have a lot of C++ code
using classes how can we 'hide' the fact that it is C++ from C
compilers?

Can we have a C header file which uses the functionality of the C++
files and compile this into a lib file?

Can anyone give me some pointers as to how to get started?

You can try something like this:

<pseudo-code sketch>
__________________________________________________ ______________

/* my_class.h
-------------------------------------------------------------*/
#ifndef MY_CLASS_H
#define MY_CLASS_H
#ifdef __cplusplus
# define EXTERN extern "C"
#else
# define EXTERN extern
#endif

Why go to all that trouble when you can just write

#ifdef *__cplusplus
extern "C" {
#endif

typedef struct my_class my_class_type;

int my_class_create(my_class_type**);
int my_class_destroy(my_class_type*);
int my_class_do_something(my_class_type*);

#ifdef *__cplusplus}

#endif

Then you don't have to mess about with casts in the C++ code.

--
Ian Collins.- Hide quoted text -

- Show quoted text -

Yes the

#ifdef __cplusplus
extern "C" {
#endif

worked.

I thought this would be harder.

Not often I say that...

[Ian Collins]

Alf P. Steinbach wrote:

* Angus:

>Hello

We have a lot of C++ code. And we need to now create a library which
can be used from C and C++. Given that we have a lot of C++ code
using classes how can we 'hide' the fact that it is C++ from C
compilers?

The C++ code will need the C++ runtime library.

Within the standards of C and C++ the only way to achieve that is to
insist that the C code using the library is called from a C++ main program.

Is it? In practice, the only constraint on any platform I've used is
that the application must be linked with the C++ compiler diver.

The best is to forget that silly idea. Using C library from C++, OK.
But C++ has additional requirements from runtime library, so other way,
generally !OK, unless you're working at a low level where you wouldn't
have to ask...

Why is it generally not OK? Provided the restrictions regarding
exception leakage are met, there shouldn't be a problem.

--
Ian Collins.

[Ian Collins]

Alf P. Steinbach wrote:

* Ian Collins:

>Alf P. Steinbach wrote:

>>* Angus:
Hello

We have a lot of C++ code. And we need to now create a library which
can be used from C and C++. Given that we have a lot of C++ code
using classes how can we 'hide' the fact that it is C++ from C
compilers?
The C++ code will need the C++ runtime library.

Within the standards of C and C++ the only way to achieve that is to
insist that the C code using the library is called from a C++ main
program.

Is it? In practice, the only constraint on any platform I've used is
that the application must be linked with the C++ compiler diver.

It's not clear exactly what you mean, but I'm guessing you mean using a
C++ compiler and linker for the main program.

Ah! parse error, main() != main program!

>>The best is to forget that silly idea. Using C library from C++, OK.
But C++ has additional requirements from runtime library, so other way,
generally !OK, unless you're working at a low level where you wouldn't
have to ask...

Why is it generally not OK? Provided the restrictions regarding
exception leakage are met, there shouldn't be a problem.

E.g. static variables of class type, internal use of exceptions, use of
standard library features that (implementation-specific) requires C++
runtime library, including internal use of exceptions in standard
library; this is a FAQ, IIRC.

True, but linking the application with the C++ compiler diver takes care
of these details. But as you say, this makes a C++ application, even if
most of the code is C!

--
Ian Collins.

[James Kanze]

On May 24, 10:27 pm, Angus <[e-mail]:

We have a lot of C++ code. And we need to now create a
library which can be used from C and C++. Given that we have
a lot of C++ code using classes how can we 'hide' the fact
that it is C++ from C compilers?

You can hide the fact from the C compilers; just make sure that
everything in the header files used by the C compilers is
`extern "C"'. That doesn't guarantee that it's going to work;
formally, using C++ requires that the function main be written
and compiled in C++. (Practically, this is usually only a
problem if you have variables with static lifetime which have
dynamic initialization. It's possible too that everything will
work fine if you follow certain implementation defined rules for
linking: maybe using g++ to link, rather than gcc, or maybe use
dynamic linking, instead of static. You'll have to enquire
specifically concerning your implementation for that, however.)

Can we have a C header file which uses the functionality of
the C++ files and compile this into a lib file?

Can anyone give me some pointers as to how to get started?

The only real problems are ensuring that the header files can be
compiled by both compilers, and ensuring that either main is
written in C++, or you've fulfilled whatever conditions your
implementation sets to ensure correct initialization of statics.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On May 24, 10:41 pm, Ian Collins <[e-mail]:

sebastian wrote:

Just enclose the user code in the C linkage namespace, eg:

extern "C" {
// C code
}

Not a lot of use if the code is C and compiled with a C compiler...

In the header file, this has to be conditional, and only present
if the compiler is a C++ compiler. And of course, the library
source files must be compiled with the C++ compiler. The
classical solution is to use something like:

#ifdef __cplusplus
extern "C" {
#endif
// Usual contents here...
#ifdef __cplusplus
}
#endif

It's ugly, but it works.

Also, of course, you have to ensure that the "usual contents"
are all acceptable and mean the same thing to both the C and the
C++ compiler. You can freely use classes, for example
(including classes with virtual functions, et al.), but you
cannot define them in a header which will be used by the C code;
the most you can do is declare them, e.g.:

struct MyClass ;

, and because this results in an incomplete type, any use in the
header is restricted to pointers and the like.

Similarly, you can't use references in the interface exposed to
C.

One frequent solution is to define a class, exactly as one would
in C++, and then provide a set of wrapper functions, something
along the lines of:

#ifdef __cplusplus
extern "C" {
#endif
struct MyClass ;

MyClass* createMyClass(...) ;
void doSomethingWithMyClass( MyClass*, ... ) ;
// ...
#ifdef __cplusplus
}
#endif

The functions then just forward to the class members.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On May 25, 5:53 am, "Alf P. Steinbach" <[e-mail]:

* Angus:

We have a lot of C++ code. And we need to now create a
library which can be used from C and C++. Given that we
have a lot of C++ code using classes how can we 'hide' the
fact that it is C++ from C compilers?

The C++ code will need the C++ runtime library.

Good point. If you don't use any standard components from the
library, nor new, nor typeid, maybe not, but then what's the
point.

Within the standards of C and C++ the only way to achieve that
is to insist that the C code using the library is called from
a C++ main program.

No. There are two separate issues involved here. Neither the C
nor the C++ standards say anything about how the compiler is
invoked; to get the C++ library with gcc, for example, you can
either invoke it as g++, or specify the library explicitly
(-lstdc++, with the normal Unix linkers). Formally, the C++
standard requires that main() be written and compiled in C++, or
you have undefined behavior. (I'm not sure, but that could also
be the case in C.) In practice, the reason for this is to
ensure correct initialization of variables with static lifetime;
if you have no static variables, it's possible that you won't
have a problem (but don't forget that std::out, etc. are static
variables). And there too, the implementation could provide
other additional arrangements. (I'm not sure, but I think if
you compile with g++, rather than gcc, one of the effects is to
cause a different crt0 to be used, and that it is this crt0
which ensures the construction and destruction of static
variables. And it's also possible that some compilers add
special information to the object file when you compile a
program in C++, or perhaps only when you compile the program
with main, so that it will work. This trick can also be used to
ensure the additional libraries.)

In Windows an alternative is to have the library as a DLL,
because Windows DLLs are more decoupled.

That sort of works in Unix, as well, if the C++ standard library
is also a DLL. (Which is generally NOT recommended, of course.)

[...]

The best is to forget that silly idea. Using C library from
C++, OK. But C++ has additional requirements from runtime
library, so other way, generally !OK, unless you're working at
a low level where you wouldn't have to ask...

It's actually a frequent requirement, and the original posters
question reflects one of the more common ways of migrating to
C++.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On May 25, 6:28 am, "Alf P. Steinbach" <[e-mail]:

* Ian Collins:

Alf P. Steinbach wrote:

* Angus:

>We have a lot of C++ code. And we need to now create a
library which can be used from C and C++. Given that we
have a lot of C++ code using classes how can we 'hide' the
fact that it is C++ from C compilers?
The C++ code will need the C++ runtime library.

Within the standards of C and C++ the only way to achieve
that is to insist that the C code using the library is
called from a C++ main program.

Is it? In practice, the only constraint on any platform
I've used is that the application must be linked with the
C++ compiler diver.

It's not clear exactly what you mean, but I'm guessing you
mean using a C++ compiler and linker for the main program.

In that case you have a C++ main program.

Or not. You can very easily compile main as a C program, but
use the C++ compiler driver (supposing such a thing exists) to
link.

In a very real sense, you're both wrong, of course: the correct
answer is that it depends on the implementation. Under Unix (or
at least Solaris and Linux), you do have a separate C++ compiler
driver (invoked by g++ or CC, rather than by gcc or cc), and
linking with that will ensure that the C++ standard libraries
are linked in. You can also invoke the linker directly, both
under Unix or under Windows, and ensure that whatever you want
is linked in however you want, but you generally have to know
very well what you are doing, what libraries are actually
required, what commands or whatever might be necessary in
addition to ensure support for e.g. exceptions or dynamic
initialization of static variables, etc., etc. And some of that
functionality may not even be accessible directly at the linker
interface; at least some implementations of C++ have generated
special code in main to ensure the initialization of statics,
for example (in which case, main does have to be compiled as
C++).

All in all, it's more complicated than just putting everything
in an `extern "C"', but most of all, it's very, very
implementation dependent.

The best is to forget that silly idea. Using C library
from C++, OK. But C++ has additional requirements from
runtime library, so other way, generally !OK, unless you're
working at a low level where you wouldn't have to ask...

Why is it generally not OK? Provided the restrictions
regarding exception leakage are met, there shouldn't be a
problem.

E.g. static variables of class type, internal use of
exceptions, use of standard library features that
(implementation-specific) requires C++ runtime library,
including internal use of exceptions in standard library; this
is a FAQ, IIRC.

As a general rule, it's probably easier (and surer) if you
ensure that main is compiled as C++. With at least some
development systems, however, it's not absolutely necessary.
What is necessary, however, even if you compile main as C++, is
that you find out the implementation specific requirements, and
respect them.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Paavo Helde]

James Kanze <ja*********@gmail.comkirjutas:

On May 25, 7:51 pm, "Alf P. Steinbach" <[e-mail]:

>* James Kanze:

[...]

>
Whether the global symbols in the object are available when
loading other dynamic objects or not. (Specific implementations
of dlopen may have other options, but this basic choice is
specified by Posix.)

and 2) symbols in the root are not available to
dynamically loaded objects under Windows, and are always
available to dynamically loaded objects under Unix.

>I'm not sure what you mean here.

I'm not that sure of the terminology myself; by "root", I mean
the code loaded as the initial binary image, before any dynamic
objects have been loaded. When you load a dynamic object under
Unix (using dlopen), you must specify either RTLD_GLOBAL or
RTLD_LOCAL: in the first case, all of the globals in the dynamic
object become accessible to other dynamic objects, in the
second, no. But since it's the operating system which loads the
root, you can't specify anything there. Under Unix, the global
symbols in the root are available to all other dynamic objects,
as if it had been loaded specifying RTLD_GLOBAL. Under Windows,
if I understand correctly, the root is always loaded as if
RTLD_LOCAL had been specified (and the choice for other
dynamic objects is made when they are build, rather than when
they are loaded---but I'm not really that certain about anything
in the Windows world).

In Windows, as you say, one decides separately for each function or class
if it is visible to other modules ("exported") or not. Other modules can
only be linked against exported symbols. In regard of dynamic linking,
there is really no significant difference between "root" .EXE and other
modules. The difference is more related to the typical way how one builds
the whole program (final .EXE depending on a number of service DLL-s).

In Windows, the dynamic dependencies are resolved and checked by the
static linker. The linker checks that all symbols are actually
resolvable, and encodes the appropriate filename into the linked module.
This pretty much means that the dependency graph of loadable modules is a
directed one, without any cycles. For implicit loading of the whole
program into memory the root module (final .EXE) has to be linked last,
thus no implicitly loaded DLL can have symbols resolved by the .EXE
module (modulo some file renaming trickery or out-of-date file versions,
of course).

However, this is different for plugin-style DLL-s, which are loaded
explicitly during the run by the program itself. These DLL-s can easily
make use of symbols defined by the .EXE module. In some cases I have seen
the .EXE itself is only a thin envelope application providing the main
GUI window frame, and 99% of the application functionality is provided by
dynamically loaded plugins, incidentally linked against to the .EXE
module for using some shared service functions.

To get this a bit more on-topic, I compare the Windows model with Linux
dynamic loader. There are both pros and cons:

Pros:
In a Windows build, if a module has been built successfully one
knows that all its dependencies have been resolved. In Linux one can
easily have a .so file with unresolved dependencies. This can be checked
and avoided of course, with a little extra work in Makefiles.

A dynamic symbol cannot be accidentally reseated into another
module, which happens to export the same symbol.

Cons:
One cannot have dependency cycles among dynamically loaded modules.
Actually I think this is rather a "pro".

A dynamic symbol cannot be willingly reseated into another module,
making things like Electric Fence cumbersome to implement, and causing
Microsoft to invent layers and layers of debugging interfaces and
subsystems.

If the modules are linked against different versions of C or C++
runtime libraries, it becomes difficult to exchange objects using
resources provided by these libraries (FILE*, malloc(), std::vector,
etc.).

Regards
Paavo

[James Kanze]

On May 26, 1:19 pm, "Alf P. Steinbach" <[e-mail]:

* James Kanze:

On May 25, 7:51 pm, "Alf P. Steinbach" <[e-mail]:

>>However, technically it should be no big deal to write

>> extern "C" int c_language_main( int, char*[] );

>> int main( int argc, char* argv[] )
{
return c_language_main( argc, argv );
}

>>and compile that top-level as C++.

>Technically, no. Practically, it depends. There may be
very good reasons for not doing so.

Such as?

Such as the fact that you don't have access to the main. It's
not part of the sub-system your group is responsible for.

Whomever's responsible should do it. :-)

Whomever's responsible has other, more important things to do.
And may not even be available, if the library is the company's
product.

There's a tension here: basic software engineering says not to
change things that don't need changing, which argues against
replacing main. There are also very strong arguments in favor
of replacing it (which you've presented). When there are
arguments on both sides, it becomes a judgement call. Most of
the time, I'd go with your suggestion, but I recognize the fact
that there will be cases where it isn't practical.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On May 27, 7:48 pm, Paavo Helde <[e-mail]:

James Kanze <[e-mail]:

[...]

To get this a bit more on-topic, I compare the Windows model
with Linux dynamic loader. There are both pros and cons:

[...]

Cons:
One cannot have dependency cycles among dynamically loaded
modules

.

Actually I think this is rather a "pro".

Yes and no. But if I understand your explination correctly, you
can in fact have cycles under Windows as well, if the modules
are explicitly loaded (e.g. as plugins), and that's probably the
only time you'd want them. (The root used, and thus depends on,
various plugins, and the plugins use common functionality in the
root.)

No, I probably expressed myself badly. The plugins are
compiled and linked after the root executable is ready. The
root executable does not know anything about the plugins by
itself. When started, it reads the names of needed plugin
files from registry or somewhere else, and loads them
explicitly with LoadLibrary() Windows SDK call. The plugins
depend on the .EXE module - this is already loaded into
memory, so everybody is happy.

The root module must know something about the plugins: an entry
point, for example. I think what you meant was that it only
knows it "symbolically", as a string constant in the code, and
not as some information in the .exe or the .dll format which the
system must exploint.

[...]

Any dynamic linking introduces any number of additional
problems with regards to version management, binary
compatibility, etc., and it's better to avoid it except
where the advantages outweigh these costs. Basically, about
the only implicit dynamic linking which I'd use is that of
the system ABI (to ensure portability to different versions
of the system) and low level libraries which can be more or
less assimilated to the system (data base interface, etc.).
Under Unix (my usual platform), I don't think I've ever
invoked dlopen except with RTLD_LOCAL, and except for the
bundled system libraries and Sybase, I don't use any
implicit dynamic linking. Under Windows, I rather suspect
that I'd do likewise---including dynamic linking for the
system API and low level functions like malloc. (But I'm
not sure: it partially depends on what is bundled with the
OS, since you don't want to have to deliver additional
system level DLL's with your application.)

Yes, there are lots of problems with dynamic linking. However,
they provide a better modularity for the whole system, and at
least on Windows, they provide a quite good additional layer
of encapsulation.

The additional modularity and encapsulation is useful in some
cases: plugins, and versionning for system level ABI's come to
mind. When those advantages outweigh the cost (or the cost is
minimal, e.g. when the dynamic object you link is bundled with
the OS, or must be provided separately anyway because of
licensing issues), then fine. But they create serious problems
with regards to deployment and versioning.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Paavo Helde]

James Kanze <ja*********@gmail.comkirjutas:

>
The root module must know something about the plugins: an entry
point, for example. I think what you meant was that it only
knows it "symbolically", as a string constant in the code, and
not as some information in the .exe or the .dll format which the
system must exploint.

There is a standard entry point called DllMain(). Windows will call that
function when loading and unloading the DLL. In that function the DLL can
register itself in the data structures by the main application in some way.
In our case the DLL typically defines some new classes derived from the
abstract base classes provided by the framework, and the registration
involves base class pointers to the derived class objects.

AFAIK Posix has similar entry and exit points called init() and fini().

Regards
Paavo

[James Kanze]

On May 28, 7:00 pm, Paavo Helde <[e-mail]:

James Kanze <[e-mail]:

The root module must know something about the plugins: an entry
point, for example. I think what you meant was that it only
knows it "symbolically", as a string constant in the code, and
not as some information in the .exe or the .dll format which the
system must exploint.

There is a standard entry point called DllMain(). Windows will call that
function when loading and unloading the DLL. In that function the DLL can
register itself in the data structures by the main application in some way..
In our case the DLL typically defines some new classes derived from the
abstract base classes provided by the framework, and the registration
involves base class pointers to the derived class objects.

AFAIK Posix has similar entry and exit points called init() and fini().

At least in Posix, those aren't entry points in the usual sense;
dlopen will only return after init() returns. They do provide
the hook for the initialization of static data, however, and
having a static variable which registers with some sort of
registry in the root is a well established technique under Unix.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]