#67 Patch: use std::function instead of std::unary_function if C++11 is available

[Jan Kohnert]

In this commit std::unary_function was removed if C++17 is active. Since std::unary_function is deprecated in C++11 already, and std::function is it's successor, and available in C++11; this patch changes behaviour to use std::function, if C++11 is available.

[Bob Friesenhahn]

On Sun, 10 Jul 2022, Jan Kohnert wrote:

In this
commit
std::unary_function was removed if C++17 is active. Since
std::unary_function is deprecated in C++11 already, and
std::function is it's successor, and available in C++11; this patch
changes behaviour to use std::function, if C++11 is available.

The reason why the code works the way it does is that it seemed that
changing this would change the shared library ABI so there would be
impact to existing users.

Is there reason to believe that the shared library ABI is somehow not
changed?

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[Jan Kohnert]

I think, the change would probably change ABI. The reason I submitted this patch was, that the current behaviour introduces a whole bunch of deprecation warnings when using modern compilers (such as gcc-12.X). And though I agree that patch updates should not break ABI, I do not see a reason why a minor update should keep ABI compatibiliy under all circumstances. YMMV, of course.

So probably this should be considered for the next minor release to reduce noise when compiling other software against GraphicsMagick, then.

[Bob Friesenhahn]

On Mon, 11 Jul 2022, Jan Kohnert wrote:

I think, the change would probably change ABI. The reason I
submitted this patch was, that the current behaviour introduces a
whole bunch of deprecation warnings when using modern compilers
(such as gcc-12.X). And though I agree that patch updates should
not break ABI, I do not see a reason why a minor update should
keep ABI compatibiliy under all circumstances. YMMV, of course.

It is useful to know about warnings with GCC 12. I have not used it
yet.

The C++ ABI has been essentially consistent (except for one minor
change to the Color class implementation, which was carefully crafted
to offer the same binary footprint) throughout the GM 1.3.X cycle
(since 2008!). However, this totally ignore changes due to the C++
compilers and the C++ run-time used.

So probably this should be considered for the next minor release to
reduce noise when compiling other software against GraphicsMagick,
then.

It may be that a mechanism to preserve the older ABI could be offered
so that distribution maintainers could use it when necessary. Then
documentation can be provided for those who care about it.

The main annoyance with this is that it would then be necessary to
change the shared library SO numbering.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[Bob Friesenhahn]

I believe that this issue has been addressed by Mercurial changeset 17480:903ae8fb5392 "Magick++/lib/Magick++/STL.h: Stop using std::unary_function in C++'11 rather than C++'17."

Thank you for making me more aware of this issue.