Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Dimitry Sibiryakov
28.01.2020 16:56, Alex Peshkoff via Firebird-devel wrote: I'm afraid nobody has plain-C solution for it. Neither I need it. C++ solution would be nice. In a mean time I had to write a wrapper and #undef every conflicting macros by hand redefining them as a constant in a namespace. --

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Alex Peshkoff via Firebird-devel
On 2020-01-28 17:11, Dimitry Sibiryakov wrote: 28.01.2020 14:55, Alex Peshkoff via Firebird-devel wrote: in plain C - "const declarations do not produce constant expressions, i.e. in C you can't use a const int object in a case label",   That's why declarations used to be separated for C and C

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Alex Peshkoff via Firebird-devel
On 2020-01-28 16:58, Dimitry Sibiryakov wrote: 28.01.2020 13:26, Alex Peshkoff via Firebird-devel wrote: Do you suggest to move all consts to FirebirdInterface.idl? That's possible way to go.   I still think that keeping constants in a separate header is better for flexibility. And definitely

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Dimitry Sibiryakov
28.01.2020 14:55, Alex Peshkoff via Firebird-devel wrote: in plain C - "const declarations do not produce constant expressions, i.e. in C you can't use a const int object in a case label", That's why declarations used to be separated for C and C++. Still the main problem is that macros can

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Dimitry Sibiryakov
28.01.2020 13:26, Alex Peshkoff via Firebird-devel wrote: Do you suggest to move all consts to FirebirdInterface.idl? That's possible way to go. I still think that keeping constants in a separate header is better for flexibility. And definitely duplicating of them for old and new APIs is a

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Alex Peshkoff via Firebird-devel
On 2020-01-28 16:46, Alex Peshkoff via Firebird-devel wrote: On 2020-01-28 16:41, Dimitry Sibiryakov wrote: 28.01.2020 13:26, Alex Peshkoff via Firebird-devel wrote: Modern code does not use defines for constants. Certainly, but the problem is with old one, particular consts_pub.h.   It is

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Alex Peshkoff via Firebird-devel
On 2020-01-28 16:41, Dimitry Sibiryakov wrote: 28.01.2020 13:26, Alex Peshkoff via Firebird-devel wrote: Modern code does not use defines for constants. Certainly, but the problem is with old one, particular consts_pub.h.   It is a matter of one-time copy-paste and search-and-replace. Perha

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Dimitry Sibiryakov
28.01.2020 13:26, Alex Peshkoff via Firebird-devel wrote: Modern code does not use defines for constants. Certainly, but the problem is with old one, particular consts_pub.h. It is a matter of one-time copy-paste and search-and-replace. Perhaps, sed can transform all "#define XXX NNN" into

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Alex Peshkoff via Firebird-devel
On 2020-01-28 13:36, Adriano dos Santos Fernandes wrote: On 28/01/2020 07:20, Dimitry Sibiryakov wrote: 28.01.2020 09:52, Alex Peshkoff via Firebird-devel wrote: Currently that will not work. We have #define isc_spb_rpr_commit_trans    15 notation in consts_pub.h which is unaffected by name

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Adriano dos Santos Fernandes
On 28/01/2020 07:20, Dimitry Sibiryakov wrote: > 28.01.2020 09:52, Alex Peshkoff via Firebird-devel wrote: >> Currently that will not work. We have >> #define isc_spb_rpr_commit_trans    15 >> notation in consts_pub.h which is unaffected by namespace. And we >> need it cause .h file may be used

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Dimitry Sibiryakov
28.01.2020 09:52, Alex Peshkoff via Firebird-devel wrote: Currently that will not work. We have #define isc_spb_rpr_commit_trans    15 notation in consts_pub.h which is unaffected by namespace. And we need it cause .h file may be used in plain C code. That's why modern headers used to co

Re: [Firebird-devel] ISC API and FB API headers

2020-01-28 Thread Alex Peshkoff via Firebird-devel
On 2020-01-27 19:51, Dimitry Sibiryakov wrote: 27.01.2020 17:45, Alex Peshkoff via Firebird-devel wrote: Am I understanding right that when ibase.h is included that constants will be in global namespace as before?   Sure. When you write in Interface.h something like this: namespace Firebird {

Re: [Firebird-devel] ISC API and FB API headers

2020-01-27 Thread Dimitry Sibiryakov
27.01.2020 17:45, Alex Peshkoff via Firebird-devel wrote: Am I understanding right that when ibase.h is included that constants will be in global namespace as before? Sure. When you write in Interface.h something like this: namespace Firebird { #include "pub_const.h" } You'll get the cons

Re: [Firebird-devel] ISC API and FB API headers

2020-01-27 Thread Alex Peshkoff via Firebird-devel
On 2020-01-27 19:16, Dimitry Sibiryakov wrote: 27.01.2020 17:08, Alex Peshkoff via Firebird-devel wrote: What about compatibility with old programs using that constants?   There are several possible cases: 1) The program already included both headers - everything is fine it will use constant

Re: [Firebird-devel] ISC API and FB API headers

2020-01-27 Thread Dimitry Sibiryakov
27.01.2020 17:08, Alex Peshkoff via Firebird-devel wrote: What about compatibility with old programs using that constants? There are several possible cases: 1) The program already included both headers - everything is fine it will use constants declared in ibase.h. 2) The program used "usin

Re: [Firebird-devel] ISC API and FB API headers

2020-01-27 Thread Alex Peshkoff via Firebird-devel
On 2020-01-27 18:12, Dimitry Sibiryakov wrote: Hello, All.   Currently Interface.h includes ibase.h which makes it a strange mix of two APIs. It was unavoidable in version 3 because that time OO API missed some essential functionality but now AFAIK it can be self-sufficient.   IMHO, these two