On 2020-06-11 18:30, Tony Whyman wrote:
On 11/06/2020 11:18, Pavel Cisar wrote:
This is not a problem for languages like Python, Java and .NET that
don't use these files at all, but C++ & Pascal are still important
languages and we should offer some better solution. At least it
should be discussed with those who use them (for example MWA
Software, developer of ibx4lazarus?).
Did I just hear my name mentioned ;)
My main gripe with the new API is really more about documentation than
anything else. It is not easy to work out how to use it except by
experimentation. E.g. with the new DecFloat type I basically had to
look at how the interface returned the BCD format value by using the
debugger to inspect the data at the byte level and then work out how
to convert this (unpacked) format into the packed tBCD record used by
FPC and Delphi - and vice versa.
That's format present in original IBM's library. They do not support
packed BCD. If you provide a link to the description of packed BCD I can
add support for it.
I still don't know how to process an INT128 type except by converting
it to a string (!) and then parsing the string.
It's compatible with __int128 from gcc. Sorry, I do not know how to
explain it in pascal way.
The "firebird.pas" file is always "processed" before it is taken into
IBX for Lazarus - which is perhaps why I am less bothered about any
imperfections in the source code. The most important need for this is
to extract the type and const declarations and separate them out in
order to avoid name space conflicts between the actual API and IBX, as
well as to limit pollution of the global name space. I also remove the
exceptions generated by the cloop code as I prefer to handle the
exceptional conditions in IBX itself.
An ability to process exception in another way is very important but
missing. Can you suggest a generic way? If yes suppose we can add it to
code generator.
The call to get the IMaster interface also assumes static linking with
the client library,
???
Why?
while IBX always dynamically loads the fb client library and then
dynamically links to each exported call using GetProcAddress.
fb_get_master_interface() is absolutely same call as all others in
fbclient, I do not understabd your problems with use of it in
GetProcAddress. At least it's posix analogue dlsym() works fine.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel