[Qt-interest] dll problem

[Andreas Pakulat]

On 14.12.08 22:44:01, Evan Teran wrote:
> 
> Not trying to be argumentative, I'm just trying to fully understand you
> points.
> 
> 
> > On 13.12.08 19:29:02, Evan Teran wrote:
> >> I've done some basic tests and it all seems to work perfectly. The
> >> plugins properly resolve the symbols which are provided by the plugin.
> > 
> > That doesn't make it a good design.
> 
> Unfortunately, no one has really said *why* it isn't good design. Either
> way the plugin has a dependency on the main application.

No it doesn't. With a core library you have a dependency on that library.
The executable can be substituted in that case. 

> The only real
> difference is how the dependency is enforce. If you pass a structure of
> function pointers, then it's enforced by the compiler. Otherwise it is
> enforced by the linker. I find that there is no technical reason why an
> application can't have exports which plugins can find useful. If it is
> in fact bad design, what is the negative consequence?

One reason would be that it doesn't work on all platforms another would be
that you need to jump through hoops to make this work on the single
platform that does support it.

Maybe "good design" isn't quite the right wording, lets say the fact that
it does work, doesn't make it less of a hack.
 
> >> The main reason I am prefering this is that there are several "utility"
> >> classes which most plugins use. So in the beginning I placed these in my
> >> main apps sources and the plugins just used them. Now with the new
> >> system because these classes need function definitions, I have to have a
> >> "core library" which all plugins link to. I can either make it static
> >> which makes the install just as simple as before but bloats the binary.
> >> Or I have have it shared and have an even more complicated dependancy
> >> tree with an extra library that has to be installed. If having the main
> >> .exe provide these classes is workable, it is simpler.
> > 
> > Thats a non-issue, because you ship .exe+.dll in the same directory on
> > windows and use RPATH on *nix to make sure the right library is used.
> 
> Point well taken, I hadn't considered RPATH as an option and I will be
> looking into that. However no matter how you cut it having an extra
> "core library" does complicate my source tree. But in the grand scheme
> of things that in itself is acceptable. So i'll concede this point.

I don't see how it would complicate the source tree, the files can
still reside where they are now and simply be put into a different target
than currently.
 
> >> Also, if the main app can export symbols, then that means I only have to
> >> update 1 place to change my API, not several (as I do now with my new
> >> plugin system).
> > 
> > Thats simply wrong. If you change the existing API (rename
> > classes/methods/functions or move stuff around) then you have to update
> > _all_ places that are using the changed API. It doesn't make any difference
> > wether the shared code is compiled into the .exe or into a shared library. 
> 
> I disagree. It is a given that the plugins would have to be updated to
> use the new names/params of functions, in all places that use the API.
> So that is immaterial, it happens no matter what the API scheme.
> However, If I have a structure which has function pointers, then I have
> to both update my API at an implementation level *and* update the
> structure which has my function pointers.

Well, then why have function pointers in the first place? Last I checked
C++ is pretty powerful without having to use function pointers, especially
if you're using Qt. So far I haven't seen code that provides a plugin
system and public API for the plugins to use/communicate with the "core" of
the application that allows to update only the plugins and not the core
application parts.

> Also, my original scheme was an "always add" concept. My API had
> namespaces like: "plugin::v1::functionName", once version 1.0 is
> finalized, the "plugin::v1" namespace is permanent, no more changes to
> it. The plan was to *never* remove something (calling it deprecated i
> considered fair game though). Instead, as the API evolves I would add
> "plugin::v2" namespaces and so on. The idea being that a plugin built
> for version 1 of the API would always work. I realize that this also
> could be done with a version variable in the structure. And always
> adding on to the end of the structure. But with namespaces, it was just,
> implicit.

Thats quite normal, but I don't see how that plays a role. If you never
remove anything from the API, then the existing code will always work. If
you introduce new API, you have to write the implementation for that new
API as well as adjust any places that should use the new API. Wether you
compile the API implementation into the executable, or into a core library
that the executable links to doesn't make any difference here.
 
> Plus a final point I forgot to mention earlier is that the function
> pointer method has no support at all for function overloading.

I don't understand where function pointers come into the game. I'm just
talking about compiling the code for the plugin system and the public API
into a shared library and let the executable link against that. There are
no function pointers involved with that. If you want an example, look at Qt
Designer's source code, it has a core library which provides some of the
functionality of the main application, allows for plugins to be used and
the main application simply combines these by some API calls into a
complete GUI.

Andreas

-- 
Beware the one behind you.