Mirek Fidler wrote:
Victor Bazarov wrote:
>>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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask