[Qt-interest] dll problem

[Evan Teran]

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. 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?

>  
>> 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.

>> 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.

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.

Plus a final point I forgot to mention earlier is that the function
pointer method has no support at all for function overloading. I used to
have several functions in my plugin API which had "default parameters".
Not in the c++'ish way, but through overloads. One version of the
function took 2 params, another took 1 and would call the 2 param
version with a default value for param #2. I actually like this over c++
style default params because you can change what the default is without
recompiling dependent source files.