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