Hi all,
a week ago Denis Simonov submitted a PR[1] regarding formatting of the
new time zone types of Firebird 4.0 (which appears sensible per se).
This requires to access new Firebird APIs which are written in C++ (the
old Interbase APIs are still provided as C code). Now the Firebird
developers have written a tool for cross language support called
CLOOP[2] which allows to access the APIs written in C++ directly from C.
However, they do not provide these C APIs officially, so Denis provided
the minimal required C API for inclusion into the PDO_Firebird extension[3].
In my opinion, this a somewhat fragile approach (especially since
CLOOP's C generator apparently hasn't been tested for a rather long
time[4]) and would personally rather use C++ to access the new APIs.
This would obviously require a C++ compiler to build PDO_Firebird (so
far a C compiler is sufficient), unless the C++ code (and the respective
functionality) would be optional.
Another drawback would affect the Windows builds; so far these just
could use the Firebird kits provided by the Firebird developers (which
contain headers and pre-built libraries), but these don't contain any
C++ libraries, so the libraries would need to be built and hosted by
winlibs[5] (at least for the time being).
I assume, however, that (Linux) distros already provide pre-built C++
libraries since the new Firebird OO API is available as of Firebird 3.0.
Maybe someone can confirm that.
So what do you think? Should we use C++ to access the new APIs, or
stick with C (and include the required declarations in PDO_Firebird)?
[1] https://github.com/php/php-src/pull/15230
[2]
https://www.firebirdnews.org/new-firebird-interface-cloop-cross-language-object-oriented-programming/
[3]
https://github.com/php/php-src/pull/15230/files#diff-e0657e20b6fc2c130f504c18ebeeac828847f17f1f8f7c3559b8fe8b2bc19928
[4] https://github.com/FirebirdSQL/firebird/issues/8197
[5] https://github.com/winlibs
Cheers,
Christoph
On Sat, Aug 10, 2024 at 4:15 PM Christoph M. Becker cmbecker69@gmx.de
wrote:
So what do you think? Should we use C++ to access the new APIs, or
stick with C (and include the required declarations in PDO_Firebird)?
There's at least one another extension that requires C++ - intl. And it's a
much more used one compared to FB. So I think the language itself is fine,
at least as long as it's used only to interface with a third-party C++
library.
--
Best regards,
Max Semenik
Hi all,
a week ago Denis Simonov submitted a PR[1] regarding formatting of the
new time zone types of Firebird 4.0 (which appears sensible per se).
This requires to access new Firebird APIs which are written in C++ (the
old Interbase APIs are still provided as C code). Now the Firebird
developers have written a tool for cross language support called
CLOOP[2] which allows to access the APIs written in C++ directly from C.
However, they do not provide these C APIs officially, so Denis provided
the minimal required C API for inclusion into the PDO_Firebird extension[3].In my opinion, this a somewhat fragile approach (especially since
CLOOP's C generator apparently hasn't been tested for a rather long
time[4]) and would personally rather use C++ to access the new APIs.
This would obviously require a C++ compiler to build PDO_Firebird (so
far a C compiler is sufficient), unless the C++ code (and the respective
functionality) would be optional.Another drawback would affect the Windows builds; so far these just
could use the Firebird kits provided by the Firebird developers (which
contain headers and pre-built libraries), but these don't contain any
C++ libraries, so the libraries would need to be built and hosted by
winlibs[5] (at least for the time being).I assume, however, that (Linux) distros already provide pre-built C++
libraries since the new Firebird OO API is available as of Firebird 3.0.
Maybe someone can confirm that.So what do you think? Should we use C++ to access the new APIs, or
stick with C (and include the required declarations in PDO_Firebird)?[1] https://github.com/php/php-src/pull/15230
[4] https://github.com/FirebirdSQL/firebird/issues/8197
[5] https://github.com/winlibs
Cheers,
Christoph
I think moving the PDO driver to use C++ is a more sensible choice.
Best regards,
Gina P. Banyard
On Saturday, 10 August 2024 at 15:13, Christoph M. Becker <
cmbecker69@gmx.de> wrote:I think moving the PDO driver to use C++ is a more sensible choice.
what would be the advantages? given the OO part at the C level is perfectly
fine in C and the actual OO parts are really zend classes and co?
I think moving the PDO driver to use C++ is a more sensible choice.
what would be the advantages? given the OO part at the C level is perfectly fine in C and the actual OO parts are really zend classes and co?
I didn't say to rewrite the whole extension.
Considering the library we are going to be depending on is in C++ it makes more sense to do what the ext/intl extension does, which is to use C++.
I do not want the project to have to deal with a broken C transpilation error created by an external tool (namely CLOOP).
If you have a better suggestion on how to deal with this issue, feel free to do so.
Best regards,
Gina P. Banyard
On Sunday, 11 August 2024 at 15:26, Pierre Joye pierre.php@gmail.com
wrote:On Saturday, 10 August 2024 at 15:13, Christoph M. Becker <
cmbecker69@gmx.de> wrote:I think moving the PDO driver to use C++ is a more sensible choice.
what would be the advantages? given the OO part at the C level is
perfectly fine in C and the actual OO parts are really zend classes and co?I didn't say to rewrite the whole extension.
Considering the library we are going to be depending on is in C++ it makes
more sense to do what the ext/intl extension does, which is to use C++.
I do not want the project to have to deal with a broken C transpilation
error created by an external tool (namely CLOOP).If you have a better suggestion on how to deal with this issue, feel free
to do so.
ah you mean only for fb? makes sense yes. While I prefer to add a thin
layer to expose it as c and keep the engine&co use in c, a tat bit easier
with little impact :)
I didn't say to rewrite the whole extension.
Considering the library we are going to be depending on is in C++ it makes
more sense to do what the ext/intl extension does, which is to use C++.
I do not want the project to have to deal with a broken C transpilation
error created by an external tool (namely CLOOP).If you have a better suggestion on how to deal with this issue, feel free
to do so.ah you mean only for fb? makes sense yes. While I prefer to add a thin
layer to expose it as c and keep the engine&co use in c, a tat bit easier
with little impact :)
That's exactly what https://github.com/php/php-src/pull/15230 does;
there is a single C++ file pdo_firebird_utils.cpp and a small header
pdo_firebird_utils.h which exposes the C API.
Christoph
On Sat, Aug 10, 2024 at 7:16 AM Christoph M. Becker cmbecker69@gmx.de
wrote:
Hi all,
a week ago Denis Simonov submitted a PR[1] regarding formatting of the
new time zone types of Firebird 4.0 (which appears sensible per se).
This requires to access new Firebird APIs which are written in C++ (the
old Interbase APIs are still provided as C code). Now the Firebird
developers have written a tool for cross language support called
CLOOP[2] which allows to access the APIs written in C++ directly from C.
However, they do not provide these C APIs officially, so Denis provided
the minimal required C API for inclusion into the PDO_Firebird
extension[3].In my opinion, this a somewhat fragile approach (especially since
CLOOP's C generator apparently hasn't been tested for a rather long
time[4]) and would personally rather use C++ to access the new APIs.
This would obviously require a C++ compiler to build PDO_Firebird (so
far a C compiler is sufficient), unless the C++ code (and the respective
functionality) would be optional.Another drawback would affect the Windows builds; so far these just
could use the Firebird kits provided by the Firebird developers (which
contain headers and pre-built libraries), but these don't contain any
C++ libraries, so the libraries would need to be built and hosted by
winlibs[5] (at least for the time being).I assume, however, that (Linux) distros already provide pre-built C++
libraries since the new Firebird OO API is available as of Firebird 3.0.
Maybe someone can confirm that.So what do you think? Should we use C++ to access the new APIs, or
stick with C (and include the required declarations in PDO_Firebird)?[1] https://github.com/php/php-src/pull/15230
[2]
<
https://www.firebirdnews.org/new-firebird-interface-cloop-cross-language-object-oriented-programming/[4] https://github.com/FirebirdSQL/firebird/issues/8197
[5] https://github.com/winlibsCheers,
Christoph
I will always support more c++ in the engine
Lanre
a week ago Denis Simonov submitted a PR[1] regarding formatting of the
new time zone types of Firebird 4.0 (which appears sensible per se).
This requires to access new Firebird APIs which are written in C++ (the
old Interbase APIs are still provided as C code). Now the Firebird
developers have written a tool for cross language support called
CLOOP[2] which allows to access the APIs written in C++ directly from C.
However, they do not provide these C APIs officially, so Denis provided
the minimal required C API for inclusion into the PDO_Firebird extension[3].In my opinion, this a somewhat fragile approach (especially since
CLOOP's C generator apparently hasn't been tested for a rather long
time[4]) and would personally rather use C++ to access the new APIs.
This would obviously require a C++ compiler to build PDO_Firebird (so
far a C compiler is sufficient), unless the C++ code (and the respective
functionality) would be optional.Another drawback would affect the Windows builds; so far these just
could use the Firebird kits provided by the Firebird developers (which
contain headers and pre-built libraries), but these don't contain any
C++ libraries, so the libraries would need to be built and hosted by
winlibs[5] (at least for the time being).I assume, however, that (Linux) distros already provide pre-built C++
libraries since the new Firebird OO API is available as of Firebird 3.0.
Maybe someone can confirm that.So what do you think? Should we use C++ to access the new APIs, or
stick with C (and include the required declarations in PDO_Firebird)?[1] https://github.com/php/php-src/pull/15230
[2]
https://www.firebirdnews.org/new-firebird-interface-cloop-cross-language-object-oriented-programming/
[3]
https://github.com/php/php-src/pull/15230/files#diff-e0657e20b6fc2c130f504c18ebeeac828847f17f1f8f7c3559b8fe8b2bc19928
[4] https://github.com/FirebirdSQL/firebird/issues/8197
[5] https://github.com/winlibs
Thank you all for your comments!
As far as I can see, there have been no objections to use C++ internally
(and nicely tucked away) in PDO_Firebird, so I've just applied
https://github.com/php/php-src/pull/15230 to be able to get feedback
from users as soon as possible.
If there are still (minor) issues to be resolved, please file tickets on
Github. If there are strong objections against requiring a C++
compiler, please raise them here, or file a ticket on Github
(https://github.com/php/php-src/issues/new/choose).
Thanks,
Christoph