[fpc-devel] interfaces vs classes in dll
Michael Van Canneyt
michael at freepascal.org
Fri Nov 30 10:26:27 CET 2007
On Fri, 30 Nov 2007, Paul Ishenin wrote:
>
>
> Michael Van Canneyt пишет:
> > On Thu, 29 Nov 2007, Mattias Gaertner wrote:
> >
> >
> > > Lazarus has the IDEIntf, the API for IDE plugins.
> > >
> > > What is better in this case: classes or interfaces?
> > >
> >
> > Classes:
> > - No reference counting mess. - Easier to grasp conceptually.
> >
> In plugin dll?
Sure. Why not ?
Obviously, the DLL needs to use packages, but that is understood.
> > - You can use ansistrings. Interfaces require widestrings. (olestrings to be
> > exact)
> >
> Who told you this? Interface <> com object
COM has nothing to do with it.
When you pass an interface that uses ansistrings to a DLL,
the ansistrings in it (or referenced by it) may be disposed
of by the wrong memory manager.
Since I assume the DLL use is the scenario that is wanted,
it de facto means that you must use widestrings.
The alternative is that you require that you can set the memory manager
of the plugin. This, in turn, is not feasible, because some plugins will
need the C memory or other memory managers. (see the whole borland
sharedmm.dll mess)
In short: DLL => No ansistrings in interface.
(and guess why: reference counting, same disease as for interfaces)
>
> > > What if someday there are packages?
> > >
> >
> > It'll work transparantly.
> >
> >
> > > What if someday there is a closed source dll plugin?
> > >
> >
> > If it is a package, there is no problem.
> >
>
> And even after extending class old class dependant plugins will work? How?
Because you use packages. A DLL will never work.
Michael.
More information about the fpc-devel
mailing list