C++ API migration to C++11/14/17

[vrogier]

Dear all,

Current Ocilib C++ API is C++03 compliant.

It was on purpose at the time It was added in order to be compatible with existing production codebases.

On a work day to day bases, I use C++17.
To be honest, extending Ocilib C++03 API is so frustrating.
I do not want to make ocilib C++ codebase unreadable by adding complex defines everywhere to use C++1x whenever supported or falling back on legacy code if not.

Thus, I was thinking for v4.7.0 (v.4.6.0 will be released this week), to port codebase to C++1x.
It will make the codebase much simpler and also be a tiny bit more performant.

Is there any reason why I should not do it?
Is it okay to at least require C++14?

Regards,

Vincent

[NormanDunbar]

Morning Vincent,

why not start a new major version - say 5.x rather than 4.7 as the C++14 version and leave a "final" release of the C++03 version as a separate release/tag in the repo? Or, as an even worse suggestion, the C++14 release could start at version, ahem, 14.x instead. (Perhaps not!)

What I'm getting at is, have a complete split from the C++03 release and the C++14 release.

Cheers,
Norm.

[vrogier]

Hi,

Thanks for the insight :)
v5.0 could become v6.0 and v4.7 become v5.0 !
Good idead:)

Regards,

Vincent

[bangusi]

So was v.4.6.0 released a couple of weeks ago as you said? I am still seeing 4.5.2 as latest https://github.com/vrogier/ocilib/releases/

[vrogier]

Hi,

Unfortunately, I was unable to publish v4.6.0 at specified release date.

I am currently on vacation and back on November 19th.

I have modified v4.6 .0 milestone release date to November 22nd.

Sorry for the delay.

Regards,

Vincent

[ghost]

Probably a 5.x version updated to C++ 17 standard is more suited for the modern times. Leaving 4.x available for back-compatibility.

In particular constexpr everything will not be possible with C++14