Subject | Re: [Firebird-Architect] External Engines (and Plugins) |
---|---|
Author | Adriano dos Santos Fernandes |
Post date | 2008-06-24T10:54:54Z |
Dmitry Yemanov escreveu:
inline implementation just for it. Libraries could (and are encouraged
to) throw ThrowError::Exception (or use ThrowError::check) and the error
will be converted to status vector. Others (...) exceptions are just
caught as unrecognized. All done without cross library boundaries.
That file was designed to facilitate C++ development. It uses even
multiple inheritance, but yes, the engine could be used by Delphi, as it
public interface is fbCppEng* functions and *Factory classes.
What we could be done, is make the C++ engine return ExternalEngine
instances for all asked languages. And add language parameter to
fbCppEngReg* functions. CppEngine.h will pass "CPP" to them. Delphi code
may register using "DELPHI". It will requires two languages in the
config. file, pointing to the same plugin_module.
Adriano
> Adriano dos Santos Fernandes wrote:This is not always true, but...
>
>> C++ libraries can throw exceptions and the plugin part (CppEngine.h)
>> embedded on them deal with exceptions and translate to the Error object.
>> There is no boundaries violation.
>>
>
> Maybe Vlad meant to say that a properly implemented dynamic library
> should never throw exceptions to the caller process.
> As long as this rule is followed, you don't need to handle C++ and Delphi pluginsCppEngine.h becomes part of user library. This header file was many
> differently in terms of exceptions.
inline implementation just for it. Libraries could (and are encouraged
to) throw ThrowError::Exception (or use ThrowError::check) and the error
will be converted to status vector. Others (...) exceptions are just
caught as unrecognized. All done without cross library boundaries.
That file was designed to facilitate C++ development. It uses even
multiple inheritance, but yes, the engine could be used by Delphi, as it
public interface is fbCppEng* functions and *Factory classes.
What we could be done, is make the C++ engine return ExternalEngine
instances for all asked languages. And add language parameter to
fbCppEngReg* functions. CppEngine.h will pass "CPP" to them. Delphi code
may register using "DELPHI". It will requires two languages in the
config. file, pointing to the same plugin_module.
Adriano