We are evaluating the possiblity to use OCILIB from our servers that are written in C++. The intention would be to phase out the Oracle OCCI API we are currently using.
When looking at OCILIB it feels like the C++ part of OCILIB has only been around for a limited time and had what seemed like a rather large modification in the 4.1.0 version in May of this year.
What does the usage look like out there? Has anyone used the C++ API for heavy traffic in large systems yet or is usage mainly limited to C-interface? Would it be possible to make a guess on future stability of the C++ API of OCILIB?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OCILIB C++ API has been introduced in January 2015 in version 4.0.0.
It is obviously was a brand new and really young C++ interface.
Thus a really young API compared the C API that is a mature, proven and widely used API.
I wouldn't be surprised if your bank, or any transport facilities you may take and or any product you may use, is using OCILIB at some point.
It is widely used in banking (my bank uses it as lots of european banks), transports (airport flight displays), industries/manufacturing, research (LHC at CERN), business(cisco webex...).
An so on...
But keep in mind that it is only a C++ wrapper around the OCILIB C API calls.
All the low level implementation code is the same.
The C++ API is more a cosmetic and nice way to use OCILIB in C++ instead of sticking with C calls and opaque pointers.
When programming in C++, you want to use STL algorithms and containers, objects, templates, adapters, lambdas and so on.
That what the C++ API allow you to do with an proven low level implementation behind.
With version 4.1.0 released in May, I did some enhancement and taken into account users feedback.
No libraries get to life perfectly shaped the first day.
Yes, it is a young API and it will evolve a bit.
Regarding the future of the OCILIB C++ API, just take a look the OCILIB C API history.
Started in 2007 with a couple of downloads the first month, it is now the established reference API to use when you're dealing with Oracle in C or other languages when performances, features and portability matters.
It has been in constant progression over the years, with always the same care and investment in both development and support.
The commitment will be the same for its C++ wrapper.
Another thing, look at OCCI: Closed C++ implementation Barely no support if you're not an Oracle client (and even if you are !) Limited compiler support (limited compiler vendors, limiter compiler versions) Using pointers making exception handling the hell Partial support of OCI Quite bloated API (OCCI code could sometimes be written with less code with OCILIB C API)
* No real support for Objects Types
And so on...
When I designed the C++ wrapper over OCILIB, I've been careful to all of theses things.
I stayed as closely as possible of the C++ spirits and paradigms.
OCILIB C++ API is more natural and easier to use than OCCI : no linkage (template API), compatible with all C++ compilers, open source, no pointer usage, only stack objects (using reference counting on OCILIB C handles), proper exception model, more featured, ...
I don't expect to make big internal changes as the ones done in May.
The C++ API will follow the updates of the C API regarding feature coverage.
Only convenient enhancements regarding it usage (like the ForEach and Adapters ones introduced in May) will now be added depending on the users feedback.
So, give it a chance :) It may be young but it worth it.
Best regards,
Vincent
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are evaluating the possiblity to use OCILIB from our servers that are written in C++. The intention would be to phase out the Oracle OCCI API we are currently using.
When looking at OCILIB it feels like the C++ part of OCILIB has only been around for a limited time and had what seemed like a rather large modification in the 4.1.0 version in May of this year.
What does the usage look like out there? Has anyone used the C++ API for heavy traffic in large systems yet or is usage mainly limited to C-interface? Would it be possible to make a guess on future stability of the C++ API of OCILIB?
Hi,
OCILIB C++ API has been introduced in January 2015 in version 4.0.0.
It is obviously was a brand new and really young C++ interface.
Thus a really young API compared the C API that is a mature, proven and widely used API.
I wouldn't be surprised if your bank, or any transport facilities you may take and or any product you may use, is using OCILIB at some point.
It is widely used in banking (my bank uses it as lots of european banks), transports (airport flight displays), industries/manufacturing, research (LHC at CERN), business(cisco webex...).
An so on...
But keep in mind that it is only a C++ wrapper around the OCILIB C API calls.
All the low level implementation code is the same.
The C++ API is more a cosmetic and nice way to use OCILIB in C++ instead of sticking with C calls and opaque pointers.
When programming in C++, you want to use STL algorithms and containers, objects, templates, adapters, lambdas and so on.
That what the C++ API allow you to do with an proven low level implementation behind.
With version 4.1.0 released in May, I did some enhancement and taken into account users feedback.
No libraries get to life perfectly shaped the first day.
Yes, it is a young API and it will evolve a bit.
Regarding the future of the OCILIB C++ API, just take a look the OCILIB C API history.
Started in 2007 with a couple of downloads the first month, it is now the established reference API to use when you're dealing with Oracle in C or other languages when performances, features and portability matters.
It has been in constant progression over the years, with always the same care and investment in both development and support.
The commitment will be the same for its C++ wrapper.
Another thing, look at OCCI:
Closed C++ implementation
Barely no support if you're not an Oracle client (and even if you are !)
Limited compiler support (limited compiler vendors, limiter compiler versions)
Using pointers making exception handling the hell
Partial support of OCI
Quite bloated API (OCCI code could sometimes be written with less code with OCILIB C API)
* No real support for Objects Types
And so on...
When I designed the C++ wrapper over OCILIB, I've been careful to all of theses things.
I stayed as closely as possible of the C++ spirits and paradigms.
OCILIB C++ API is more natural and easier to use than OCCI : no linkage (template API), compatible with all C++ compilers, open source, no pointer usage, only stack objects (using reference counting on OCILIB C handles), proper exception model, more featured, ...
I don't expect to make big internal changes as the ones done in May.
The C++ API will follow the updates of the C API regarding feature coverage.
Only convenient enhancements regarding it usage (like the ForEach and Adapters ones introduced in May) will now be added depending on the users feedback.
So, give it a chance :) It may be young but it worth it.
Best regards,
Vincent