The best way to create a plugin based application in C++?

[Paciente8159 AKA Klayman]

Hi,

I have a couple of doubts reggarding a plugin based application in C++?

I want to build a c++ plugin based app. I have searched alot of things
in the net but I still don't know how to start this.

For example:
I want the plugin to be able to expose functions and HANDLES (for
synchronization with WaitForSingleObject for example).
I want the plugin to internally be able to run a thread which is called
by an exposed function and stopped that thread by an other function.

I WOULD LIKE TO AVOID auto generated code because..well I didn't do it
and I will get a hard time trying to correct an error. The other
problem is the C++ sintax. I would like to keep it clean. Perhaps this
is a dum' question but why does C++ has so many types for the same
thing? Why does it have to be a long, LONG, HRESULT, etc... Why just
not long and thats it.

1º - Which strategy is best in order to perform this task? A simple
DLL, or more of a COM style dll with interfaces?

2º - How do I develop that strategy (the plugin structure, the
wrapper, etc..)?

3º - Regarding variables, threads and HANDLES. How should they be
created? In a class? Global variables?
How does the cliente application uses and see them and uses them?


Thanks in advanced...

 

[Victor Bazarov]

I have a couple of doubts reggarding a plugin based application in
C++?

Why is that a question? How should we know if you have doubts?

I want to build a c++ plugin based app. I have searched alot of things
in the net but I still don't know how to start this.

Every C++ program has to have the 'main' function. Here is its simplest
implementation:

int main()
{
}

'return 0' is optional. Start by introducing the translation unit into
your program and placing the 'main' function there.

For example:
I want the plugin to be able to [..]

I WOULD LIKE TO AVOID auto generated code [..]

1º - Which strategy is best in order to perform this task? A simple
DLL, or more of a COM style dll with interfaces?

2º - How do I develop that strategy (the plugin structure, the
wrapper, etc..)?

3º - Regarding variables, threads and HANDLES. How should they be
created? In a class? Global variables?
How does the cliente application uses and see them and uses them?

None of those question relate to C++ langauge. I strongly recommend
you to post your questions to 'comp.software-eng'. The fact that you
want to implement your architecture in C++ has no relevance here.

When you encounter a C++ _language_ problem, come back, read the FAQ,
post according to the guidelines, and we will try to help you.

V

 

[Mirek Fidler]

I WOULD LIKE TO AVOID auto generated code [..]

1º - Which strategy is best in order to perform this task? A simple
DLL, or more of a COM style dll with interfaces?

2º - How do I develop that strategy (the plugin structure, the
wrapper, etc..)?

3º - Regarding variables, threads and HANDLES. How should they be
created? In a class? Global variables?
How does the cliente application uses and see them and uses them?

None of those question relate to C++ langauge. I strongly recommend
you to post your questions to 'comp.software-eng'.

Actually, many of those question are highly relevant to C++ language
design, or at least common implementation.

E.g. "simple DLL" approach using C++ has the problem that to maintain
plugin interfaces can be somewhat difficult as adding any virtual
function or data member anywhere breaks the interface. This is quite
C++ specific problem.

With "COM style" original poster does not want to discuss windows
architecture, but rather avoiding large portion of above problem by
exposing just interfaces based on virtual methods (possiby pure
virtual).

I believe that question 3 mostly deals with problem of wrapping
resources and distributing the problem between plugin interface and
plugin / application code.

If you are using "COM like" interfaces, you have resource management
problem, because these interfaces are usually exposed as pointers. So I
guess the question there was whether, how and where to provide helper
classes to manage interface lifetimes. Or maybe to use PIMPL?

Many interesting and C++ related problems. Deserves discussion here
IMHO.

Mirek

 

[Victor Bazarov]

I WOULD LIKE TO AVOID auto generated code [..]

1º - Which strategy is best in order to perform this task? A simple
DLL, or more of a COM style dll with interfaces?

2º - How do I develop that strategy (the plugin structure, the
wrapper, etc..)?

3º - Regarding variables, threads and HANDLES. How should they be
created? In a class? Global variables?
How does the cliente application uses and see them and uses them?

None of those question relate to C++ langauge. I strongly recommend
you to post your questions to 'comp.software-eng'.

Actually, many of those question are highly relevant to C++ language
design, or at least common implementation.

Are you saying that by answering those questions we can figure out how
to design C++ better? Or are you saying that the design of C++ already
dictates the answers to those questions?

E.g. "simple DLL" approach using C++ has the problem that to maintain
plugin interfaces can be somewhat difficult as adding any virtual
function or data member anywhere breaks the interface. This is quite
C++ specific problem.

This is not a language problem. It's a system maintenance problem.
And it doesn't relate to C++ alone, but to any language where virtual
functions are implemented. That is why the answer cannot be given
in terms of C++ language, can it?

Choosing "simple DLL" over "COM" is based on the mere merits of those
approaches, and NOT on any features of the language. Virtual functions
are means to an end, they don't have any trait which would make them
a decision-making point, speaking in the language terms. It is purely
a *software engineering* decision.

With "COM style" original poster does not want to discuss windows
architecture, but rather avoiding large portion of above problem by
exposing just interfaces based on virtual methods (possiby pure
virtual).

So? How is it a language problem? If he wants to expose it, let him.
He's not really asking "how", is he? Because that's a COM question,
isn't it?

I believe that question 3 mostly deals with problem of wrapping
resources and distributing the problem between plugin interface and
plugin / application code.

And how is that a language problem, again? The language does *not*
make any of those things preferrable. It all depends on the choice
of the development team and/or the designers of the library/app.
How any of their concerns can be addressed in terms of C++?

If you are using "COM like" interfaces, you have resource management
problem, because these interfaces are usually exposed as pointers. So
I guess the question there was whether, how and where to provide
helper classes to manage interface lifetimes. Or maybe to use PIMPL?

PIMPL is *not* a feature of the language. And it does not serve any
*language*-related problem, does it? It serves the purpose of reducing
the compilation time by reducing dependencies.

Many interesting and C++ related problems. Deserves discussion here
IMHO.

Good. Prove me wrong. Answer the OP's concerns in terms of the C++
language alone. Keep in mind, though, that as soon as you start
comparing technologies ("COM vs simple DLL") based on their own merits,
you're off topic.

V

 

[Mirek Fidler]

Are you saying that by answering those questions we can figure out how
to design C++ better?

I guess designing better C++ is not the main purpose of this group.

Or are you saying that the design of C++ already
dictates the answers to those questions?
Yes.

This is not a language problem. It's a system maintenance problem.
And it doesn't relate to C++ alone, but to any language where virtual
functions are implemented.

In no language the problem is as prevailing as in C++.

That is why the answer cannot be given
in terms of C++ language, can it?

Why not?

approaches, and NOT on any features of the language. Virtual functions
are means to an end, they don't have any trait which would make them
a decision-making point, speaking in the language terms. It is purely
a *software engineering* decision.

Everything is a *software engineering* decision.

So? How is it a language problem? If he wants to expose it, let him.
He's not really asking "how", is he? Because that's a COM question,
isn't it?

That has nothing to do with COM.

And how is that a language problem, again?

So it is forbidden to discuss merits and pitfalls of e.g.
boost::shared_ptr here?

Is not reference counting just generic programming technique?

Good. Prove me wrong. Answer the OP's concerns in terms of the C++
language alone. Keep in mind, though, that as soon as you start
comparing technologies ("COM vs simple DLL") based on their own merits,
you're off topic.

The real question is: What are problems of inter-modul interface when
using *C++* to implement modules?

If you replace "C++" in the question with "Objective C" or "Visual
Basic" or "C#", answers will be radically different. Therefore this is
strongly C++ related problem.

Any "answer" has to deal with following C++ specific features:

- C++ lacks garbage collector
- C++ lacks introspection
- C++ object layout makes any interface extremely fragile with respect
to module version

Mirek