C++17

[zofer1]

I would like to discuss the C++17 changes.
While it is great to benefit from C++17 features in this project, I see little benefit in forcing all clients that need to compile and link with this project but don't use C++17.
C++17 has introduced some breaks in selected areas and and is not considered a drop in replacement for earlier versions. Moreover, new features makes BWC breaks by definition.
Adding C++17 constructs in public headers of Poco makes it impossible for such projects to compile with it.
A few examples:
Using "__has_include" is only C++17 (Platform.h)
Replacing is_same with is_same_v (Types.h)
While it has some benefit, this is mostly the task of config or CMake to decide such things.
The down side is imposing C++17 on client software.

[obiltschnig]

Eventually we'll want to use more C++17 features, and also move on to C++20 not too far in the future. C++17 is now 8 years old, and there really is not much point on being stuck on C++14, a 10+ years old standard.

[zofer1]

In the code, C++17/20 may have some benefits.
I also share your insight that C++17 is 8years now.
But, there are projects that goes back a long time with a substantial code base.
There is no ROI for such projects to upgrade to C++17 and refactor working code just because it is there.
The benefit of using C++17 constructs in public header file of Poco is minimal in my mind, and on the other hand blocks such projects from using or upgrading Poco in recent versions.
Similar discussion can made for supporting C++11ABI

[aleks-f]

At one point, we had macros for backward compatibility, but it was very hard to keep orderly because it is essentially another "platform" to support, in addition to operating systems and build systems.

If you are asking for header-only backwards compatibility AND you are willing to maintain it, perhaps it makes sense. Make a concrete proposal in the form of pull request and we'll take a look at it.

[matejk]

Why is it necessary to upgrade an older project to the latest version of Poco?

If it works properly with an older version of Poco, continue using it.

[zofer1]

To some extent this is to modify the existing platform not presenting a new one. In the Platform.h we check the existence of a header file by using C++17 constructs. This can be replaced with a check by cmake. The seconf check that has recently changed to C++17 construct is to check if int8 is the same as signed char. This check can be done by cmake as well. No need to mess around with macros in platform.h. I will create a PR for this.

As for the second comment, Poco upgrade is usually to use new features like Prometheus, and to address CVEs

[aleks-f]

To some extent this is to modify the existing platform not presenting a new one. In the Platform.h we check the existence of a header file by using C++17 constructs. This can be replaced with a check by cmake. The seconf check that has recently changed to C++17 construct is to check if int8 is the same as signed char. This check can be done by cmake as well. No need to mess around with macros in platform.h. I will create a PR for this.

Beware that we still use gmake and preconfigured MS Visual Studio projects. Not strictly officially supported, but we find it nice to have for our own internal use.

[mkrivos]

Hi All

I'll try to add a few observations here.
My opinion is subjective, and I might be wrong.

I've already participated in similar discussions in my career on the topic of when a library should move forward and when it should stay behind. These are certainly impactful decisions that need to be made carefully.

Currently, there is support for C++17, with C++20 on the horizon. In my opinion, every newer C++ standard is not only more productive, but, more importantly, safer. This is an area where future standards will focus on most. Moreover, using a newer standard in the compiler doesn’t cost anything extra, so this possibility is essentially a gift that should be wisely utilized—granted that the job, company, and environment allow it.

Poco is an OSS project, and any help—even in the form of more usable and safer code—should, in my opinion, be embraced immediately. Features like std::span, std::string_view, std::optional, std::variant, std::any, , and others have breathed new life into many older projects. Every line of code where a developer can utilize these features is money saved.

However, there are also projects where Poco is used on very old platforms.

The question now is whether it makes sense to stop developing the Poco library entirely because of these few projects, and not take advantage of what is readily available.

In my opinion, this could be solved by declaring version 1.13 as LTS, with only CVE fixes applied. If the old code has worked correctly so far, it won't require any new features (or introduce new bugs as a result).

The question remains: who would be willing to maintain the LTS version, and under what conditions?

One last observation from personal experience—maintaining C++ headers for C++14 while the code is compiled under C++17 is neither simple, nor useful, nor pleasant. In the end, neither group will be happy, IMHO.

C++17 support in compilers: https://en.cppreference.com/w/cpp/17

Survey?

[aleks-f]

The question remains: who would be willing to maintain the LTS version, and under what conditions?

Yes, that is the main question. Whoever needs it should step in by either doing the necessary work or paying someone to do it.

One last observation from personal experience—maintaining C++ headers for C++14 while the code is compiled under C++17 is neither simple, nor useful, nor pleasant. In the end, neither group will be happy, IMHO.

Agreed.