Dimitry Sibiryakov wrote:

>
>
>> Also,
>>you've apparently forgotten that the API is not intended for
>>application program use -- again, it could, but needn't --
>>
>>
>
> Jim, Jim, Jim, didn't I warned you about using right words? Re-read
>your statement. Application Programming Interface (AKA API) that is
>not intended for application use?!? It is the best joke I've read
>last year.
>

Dimitry, perhaps you've heard of the concept of layers? That's what
we're talking about, layers.

The API we're discussion is an architecturally controlled Application
Program Interface. Any code that wishes to do so, may. If they do,
they may find it is intuitive that other APIs because it is designed for
efficiency, extensibility, and generality.

Let me give you two examples that may help. You are probably famility
with the Unix fopen(), fprintf(), and fclose() calls. They're generally
regarded as part of the C/Unix API. It turns out that they aren't part
of the API at all, but are layered on open(), write(), and close(). The
layered calls are more convenient to use in most cases, but sometimes it
is necessary to drop down to the lower level. Firebird, for example,
uses the lower layer.

Here's a another example closer to home. The "real" engine API is blr
and message based -- isc_attach_database, isc_compile_request,
isc_start_and_send. In Firebird 2, there are DSQL calls layered on
these. The lower level calls are intended for both machine generation
(gpre) and tools (qli), not human use. Humans use SQL and GDML. If you
are arguing that DSQL is not part of the Firebird API, you are
technically correct -- it isn't -- it's a layer. In Vulcan, however,
the SQL calls are part of the API. Go figure.

Dimitry, I don't think you are nearly as dumb as you pretend to be. I
think you are throwing smoke and ridicule at something to wish to stop
but not have the technical arguments to do so. I will continue to
respond to your foolishness because it has educational merit for other
people. But let's neither of us be under any illusions that your silly
arguments have any bearing on the serious questions at hand.

> Then, normal exception throwing-catching may work because all this
>will happened in one solid module, no?
>
>

Read Nickolay's post. He explained it rather well.

> Callbacks that receive callbacks as parameters. API which is not
>API. Pseudo-object for managing objects. What kind of hallucinogens
>do you use to invent all these things? I'd like to have some. ;-)
> The first thing that every error handling pseudo-objects have to do
>is copy all useful information from received error object into
>something internal because livetime of the error object is
>unpredictable. What did you say about data copying?
> Because of polymorphism error handling pseudo-object can't know how
>many data error object may provide. What did you say about freedom?
>

Callbacks that receive callback as arguments are called objects. That
what objects do. The callbacks on objects are called methods. The
object oriented programmng works by invoking methods on objects that are
passed around.

Dimitry, I may have gotten it wrong. Maybe you really are as thick as
you seem to be.

Let's cut the crap. If you have something to say, say it.

> Object-oriented API? Or pseudo-object-oriented API? They are two
>big differences, I'd say.
>

Then, my friend, you need to learn how C++ works. C++ was originally
designed and implemented as C preprocessor -- the early C++ "compilers"
produced C. The preprocessors converted a C++ class containing virtual
methods into a C struct with pointer to a virtual function vector. A
virtual function call was translated into an indirect call through the
virtual function pointer.

The C++ runtime environment is compiler specific. Microsoft puts the
virtual function vector at the front, g++ puts it at the back. This
means they can't invoke methods on each other's objects. To make sure
this doesn't accidentally happen by accident, each poisons their object
modules to produce link errors if modules from different compilers are
mixed. The solution to mixing is to define all APIs as "extern C".
Pseudo-objects are C++ objects declared as "plain old data" C
structures. In the case of the Microsoft compiler, they are in fact
usable as C++ objects.

If you need more detail, read about the Java JNI, which does exactly
this. I'm sure Roman would be happy to help you understand it.