On 08/08/2014 14:19, Dimitry Sibiryakov wrote:
> 08.08.2014 18:47, Adriano dos Santos Fernandes wrote:
>> It works provided that who called the method that returned the new
>> object was compiled together (or with the same API version) of who is
>> calling the object method. In most of cases I'd imagine, this is true.
>    If this assumption is true, then checking of versions, upgrading and 
> refcounting is 
> complete overkill. Your design can be simplified to following:
>
> 1) Plugin/Provider DLL exports plain C handle-based API. This solve compiler 
> and language 
> compatibility issues because all compiler's authors have agreement about 
> plain C ABI.
> 2) Plugin manager after loading plugin DLL assign pointers to exported 
> functions to set of 
> imported function variables, leaving missing entries to NotImplemented() 
> stub. This solve 
> versions compatibility issues.

Plugin manager? Everyone can create and return instances. Plugin manager
only loads main plugin objects.

>
>    This architecture solves all problems with version, language and compiler 
> incompatibility and does not cause performance and memory penalty in contrast 
> with yours.
>
It does not even solve the problems.

In contrast, last Alex/me solution does not add memory and performance
problems (each call is a single virtual call) with a check (indirect
access) for upgrade when a function returns a new object.

Even the generated files are not complicated.

And the implementation files are straightforward.


Adriano


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to