[Qt-interest] dll problem

Andreas Pakulat apaku at gmx.de
Mon Dec 15 19:48:26 CET 2008


On 15.12.08 12:38:20, Evan Teran wrote:
> I think you have missed half of my desired functionality. There are two
> parts.
> 
> #1. Have functions/classes which any plugin or the main application can
> use. These are covered by the core library easily. Mostely a non-issue,
> in fact it is only an inconvenience because of my initial plugin design
> not having a "core library".
> 
> #2. I want plugins to be able to use functions and data found in the
> main application. I believe you have overlooked this. Either that, or
> you would have pretty much the entire application reside in a library.

I haven't missed that, I'm suggesting the latter as a good way of doing
things :) In fact thats exactly what quite some of the larger plugin-based
apps are doing (KOffice, KDevelop, Qt Designer).
 
> The only real alternative I see is to have nearly all of the main
> application provided by the "core library". To be honest, that feels WAY
> more hacky than simply letting plugins touch certain parts of the main
> application.

IMHO not, because having the data and functions in a core shared library
you're clearly communicating to plugin developers that this is public API
and they should use that. This is IMHO not the case when extracting the
symbols from the executable and basically "linking" against the executable.

It also depends on how you design your application for extensibility,
there's apps that simply allow plugins to add some additional features,
with some basic access to the applications core data. The other extreme is
to actually implement the application in terms of plugins, this will
probably also mean that plugins have dependencies between each other.
 
> >> 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.
> 
> Once again, having practically the entire application be found in a
> library is just a workaround for the fact that something like -rdynamic
> doesn't exist on MSVC. Now *that* feels like a hack to me.

I guess we can just agree to disagree on that point :)

Andreas

-- 
You will be winged by an anti-aircraft battery.



More information about the Qt-interest-old mailing list