Firebird already has a C++ Interface that is widely if not universally used by C++ Developers (including myself) to access the Firebird API. This is IBPP. IMHO, it is well designed, stable and fit for purpose. It compares well with similar libraries such as MySQL++ and Oracle OCCI.
On the other hand, the FIrebird project has developed a second and incompatible C++ interface as part of FB3. This has to be an implicit criticism of IBPP and the new interface would be expected to be a big improvement on IBPP, if existing C++ applications are to be migrated to the new interface or for new applications to choose it over IBPP. It clearly must have a wow factor if it is to take Firebird boldly into the future. However, when I compare IBPP with the FB3 interface, a different picture emerges. Database attachment and transaction management are broadly similar (so nothing here to get you excited), but there is a big difference in data handling. IBPP (as do MySQL++ and Oracle OCCI) handles all the messy details of accessing column data and setting input parameters. It allows you to access each column by position or name and handles type conversion for you. This is where the real value added nature of IBPP comes in. C++ is more than just being Object Orientated: it is about being able to express the algorithm in a natural fashion without having to get down amongst the bits. IBPP allows you to do this. In comparison, the new FB3 API appears to deliver each row into an untyped (unsigned char*) buffer, which the user then has to parse using a separately provided metadata structure. When faced with a choice between IBPP and the new FB3 interface, I can't see why any C++ Programmer would choose an interface that meant poking around in a buffer, when an interface was available that provided type safe access to column data. So what is the point of this new interface? It is certainly not there to improve the Firebird experience for Delphi/Pascal, 'C' or PHP clients. It will not replace IBPP. I suppose IBPP may be rewritten to use the new interface itself - although the motivation to do is unlikely to be very strong and will, in any case, not make any difference to the IBPP user. If IBPP is not rewritten to use it then who will? I can't see the justification for the new interface. It does not improve on IBPP and will not make Firebird more acceptable to the C++ community while, at the same time, it will lessen the attractiveness of Firebird to just about everyone else. A uniquely pointless exercise. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel