fb-cpp: a C++ client library for Firebird

[Adriano dos Santos Fernandes]

Hi!

I'm creating fb-cpp, a C++ client library for Firebird.

Repo: https://github.com/asfernandes/fb-cpp/

Docs: https://asfernandes.github.io/fb-cpp/

The development is in early stage, so there is not yet any compromise
with backward compatibility.

It's good moment to contribute with design decisions and code. ;)


Adriano

[Lucas Schatz]

Nice

If you wanna use, I had implemented a simple parser for named parameters, it's available in the ibpp code inside Flamerobin project

GitHub.com/mariuz/flamerobin

--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/firebird-devel/ad9d4129-b512-4ec5-82e9-63da47f04fa9%40gmail.com.

[Adriano dos Santos Fernandes]

On 10/26/25 18:31, Lucas Schatz wrote:
> Nice
> If you wanna use, I had implemented a simple parser for named
> parameters, it's available in the ibpp code inside Flamerobin project
> GitHub.com/mariuz/flamerobin
>

I may understand named parameters in a tool or in a library that follow
common conventions of a technology or standard, but I think a C++ client
that has nothing related to that should not have it IMO.

I'm instead in favor of it in the native client library.


Adriano

[Piergiorgio Valli]

Hello,

as emerged from the ITdevconf in Italy, Firebird is strictly SQL standard, making it difficult to include SQL syntax that is helpful from a programmer's perspective. 

Therefore, the driver can improve the utilization and experience of Firebird. For example, a bulk insert or named parameters.

Best Regards

Pier

--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/firebird-devel/f7bb3f5f-869d-4d44-be4b-537cdb595c25%40gmail.com.

[Mark Rotteveel]

On 29/10/2025 09:15, Piergiorgio Valli wrote:
> as emerged from the ITdevconf in Italy, Firebird is strictly *SQL
> standard*, making it difficult to include SQL syntax that is helpful

> from a programmer's perspective.

That is an oversimplification. We generally prefer SQL standard solution
over custom extensions, but that doesn't mean that custom extensions are
totally "forbidden".

As an aside, the SQL standard offers a whole lot of things that Firebird
currently doesn't yet support.

As I understand it, what Adriano means that they won't add named
parameters in this driver by means of emulation (like some drivers for
other platforms do), and that if it's going to support that, it needs to
be supported by Firebird itself natively, or possibly that such
emulation would need to be in fbclient.dll, so drivers don't need to
reinvent the wheel (though, I wouldn't be in favour of such a solution,
as it would still leave wire protocol reimplementations in the cold;
server-side support would cover both).

> Therefore, the driver can improve the utilization and experience of
> Firebird. For example, a bulk insert or named parameters.

If by bulk insert you mean batch updates, Firebird already has that. If
you mean table-value expressions (for example multiple rows in a VALUES
clause of an insert, which BTW *is* standard SQL), I believe there are
plans for it in Firebird 6, though not 100% sure.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 29.10.2025 9:37:
>> Therefore, the driver can improve the utilization and experience of Firebird.
>> For example, a bulk insert or named parameters.
> If by bulk insert you mean batch updates, Firebird already has that. If you mean
> table-value expressions (for example multiple rows in a VALUES clause of an
> insert, which BTW *is* standard SQL), I believe there are plans for it in
> Firebird 6, though not 100% sure.

If I'm not mistaken, named parameters are also part of SQL standard in form
of <host parameter name> ::= <colon> <identifier>.

--
WBR, SD.

[Mark Rotteveel]

In the SQL standard, host parameters are only used for
"externally-invoked procedures", not generally in statements.

Regarding dynamic SQL, the standard says (SQL:2023, 4.32.2):
"""
In SQL-statements that are executed dynamically, the parameters are
called dynamic parameters (<dynamic parameter specification>s) and are
represented in SQL language by a <question mark> (?).
"""

In other words, by the standard, dynamic SQL does not know named
parameters, only positional parameters marked by ?, and support for
named parameters in dynamic SQL would therefor be a non-standard extension.

Mark
--
Mark Rotteveel

[Mark Rotteveel]

And to be clear, following the syntax for host parameters like in
"externally-invoked procedures" as defined in the standard is probably a
good starting point for such a non-standard extension as it already
matches what most drivers use in emulation, and what we use in PSQL
(basically our "externally-invoked procedures).

Mark
--
Mark Rotteveel

[Adriano dos Santos Fernandes]

On 10/29/25 05:37, 'Mark Rotteveel' via firebird-devel wrote:
>
> As I understand it, what Adriano means that they won't add named
> parameters in this driver by means of emulation (like some drivers for
> other platforms do),

Correct.

> and that if it's going to support that, it needs to
> be supported by Firebird itself natively, or possibly that such
> emulation would need to be in fbclient.dll, so drivers don't need to
> reinvent the wheel (though, I wouldn't be in favour of such a solution,
> as it would still leave wire protocol reimplementations in the cold;
> server-side support would cover both).
>

Not emulation in fbclient, but direct support in engine so custom
implementation of wire protocol could also use it.

I started it once and should revisit this topic.


Adriano

[Denis Simonov]

I think the idea of ​​supporting named parameters in the engine is absolutely right. There are many reasons for this:
- the client may be older than the server and not understand the syntax of some operators;
- native parsers in libraries may also lag behind and not understand the specifics of new statements;
- some SQL operators cannot be parsed syntactically without accessing the server itself. For example, `CALL proc(:a, :b)`. 

It's impossible to tell from the syntax which parameters are input and which are output.

среда, 29 октября 2025 г. в 13:44:22 UTC+3, Adriano dos Santos Fernandes:

[Tomasz Tyrakowski]

Writing from the point of view of someone working mainly with languages
other than C++: if you make the code very C++ specific, it will be
hardly usable in other programming languages. By "specific" I mean
depending heavily on the preprocessor, templates, etc.
From my experience of implementing a Firebird driver (client library)
for the Dart language, I can say I struggled a bit with mapping the
Firebird client interfaces to plain function pointers, to be used by
Dart FFI (foreign function interface). Fortunately, the FB client
library has object-oriented logic, but is not C++-specific, and can be
accessed from other languages (its implementation is in C++, but the
interfaces contain method tables with plain C function pointers, blessed
be whoever came up with this idea). That's what I mean by not being
C++-specific. If, instead of the interfaces, libfbclient just exported a
bunch of C++ classes, it would be _way_ harder to use it outside C++.
I don't have anything against C++ (even used to teach it at academia and
shipped some software written in it), but the memory layout of C++
objects is compiler-specific, and passing objects even between code
compiled with different C++ compilers on the same platform (e.g. MSVC vs
gcc vs clang on Windows), and using them on the other side as fully
functional objects, not just opaque pointers, is hardly possible. As
long as C++ ABI is not fully standarized, that's how things are going to be.
So, if you design your library in such a way that its functionality can
be wrapped in a set of plain C functions (I don't mean it needs to be
implemented in C, just that its functionality can be expressed as a set
of extern "C" functions, exported from a dynamic library and imported by
code in another language, which usually supports only the C ABI), the
potential application of your tool will be much wider than just C++
code. I don't even mean you should provide the plain C interface, just
design the functionality so that it would be possible for somebody else
to create one.
I don't have any specific numbers close at hand, but I guess nowadays
C++ is not the first choice language for business applications.
That is just my personal opinion, I don't want to start a religious war
on which language is better and should be used no matter what (there's
no such thing as "better in every way and for every application" when it
comes to programming languages), so please treat it just as my personal
piece of advice, expressed with much sympathy for your project.

best regards
Tomasz

[Denis Simonov]

Tomasz Tyrakowski,

In my opinion, you're misunderstanding the purpose of the library https://github.com/asfernandes/fb-cpp/, which is perfectly clear from its name. 

It's a higher-level wrapper over the Firebird API for C++.

I think other programming languages ​​require different wrappers, and perhaps different approaches. 

And it's unlikely that any of the developments used here can be used elsewhere without significant adjustments.

среда, 29 октября 2025 г. в 14:26:40 UTC+3, Tomasz Tyrakowski:

[Adriano dos Santos Fernandes]

On 10/29/25 08:36, Denis Simonov wrote:
> Tomasz Tyrakowski,
>
> In my opinion, you're misunderstanding the purpose of the library
> https://github.com/asfernandes/fb-cpp/, which is perfectly clear from
> its name. 
> It's a higher-level wrapper over the Firebird API for C++.
>
> I think other programming languages ​​require different wrappers, and
> perhaps different approaches. 
> And it's unlikely that any of the developments used here can be used
> elsewhere without significant adjustments.
>

Completely true, and if you look at the code you will see that the most
part of its code is about data type conversions.

During the course of its development, I also implemented
https://github.com/FirebirdSQL/firebird/issues/8761 so others client
wrappers do not implement this too.

I'm also going to propose backport of #8761 to older Firebird versions
so this type of custom code can go away with the time.


Adriano

[Tomasz Tyrakowski]

On 29.10.2025 at 12:36, Denis Simonov wrote:
> Tomasz Tyrakowski,
>
> In my opinion, you're misunderstanding the purpose of the library
> https://github.com/asfernandes/fb-cpp/, which is perfectly clear from its
> name.
> It's a higher-level wrapper over the Firebird API for C++.
>
> I think other programming languages ​​require different wrappers, and
> perhaps different approaches.
> And it's unlikely that any of the developments used here can be used
> elsewhere without significant adjustments.
>

It is quite possible I misunderstood the purpose of the library, as you
say. Maybe it was my wishful thinking, but I expected an easier to use
FB client, abstracting away some low-level stuff (simplifying the
handling of messages for example).
If it's a C++ wrapper around C++ Firebird client, then OK - my remarks
were probably off the point. The repo's readme doesn't say what the
intended application of the library is - if it's mainly for building /
expanding Firebird tooling, and not for business apps, I'm fine with it.

regards
Tomasz