[fpc-devel] interfaces vs classes in dll

Paul Ishenin ip at kmiac.ru
Fri Nov 30 10:56:21 CET 2007


Michael Van Canneyt wrote:

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

I mean what is easier to grasp conceptually when you use class in dll 
instead of interface? I think nothing. Where is written that either we 
use (classes + packages) or (interfaces - packages)?

Why you should use reference counting?

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

Same misreading. Nobody written interfaces without packages. So you can 
use any type inside interface.

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

And how package system will redirect pointers from old plugin dll (which 
is also package) to new methods locations?

Best regards,
Paul Ishenin.




More information about the fpc-devel mailing list