Allow lib to compile with older C++ versions

[darksylinc]

The new functionality that requires newer C++ versions has been disabled.
Fortunately the API already supports returning error when the operation failed or was unsupported.

This is a DRAFT because I'm testing this functionality yet to make sure there are no surprises but it appears to be working.

[agruzdev]

Hello. I do think the new functionality can be supported in older C++ versions too...
The main question is how old C++ version do you want to use?

[darksylinc]

Hi!

These are my thoughts:

In my experience, trying to keep functionality working on multiple C++ versions is a PITA to maintain in the long run, because you always get some silly breakage between compilers and platforms ("this header is missing", "this function is not available", "the compiler lies about this macro you're using in #ifdef", etc).

Right now FreeImage appears to be dead. There are traces online that there was development further than 3.18 but the CVS seems to be gone now (I can't get read-only access either with the CVS client or the rsync command SourceForge suggests).

FreeImage 3.18 is starting to rot because it fails to compile on modern compilers (particularly EXR dependency fails with C++17) and other dependencies (libpng, etc) are awfully out of date (which means lots of CVEs).

Your fork is the only one easily searchable via Google & DuckDuckGo that addresses these issues:

1. Fixed build errors with modern compilers.
2. Updated dependencies to much newer versions.
3. Is a "drop in" replacement for vanilla FreeImage (this is HUGE!).

On top of this you added new functionality, but it depends on C++17.

For those like me that only wants a drop-in replacement that fixes points 1 & 2, I don't care about the new functionality (at least for now). I just want to update FreeImage dependency and forget about it.

If someone wants the new functionality, they can bump their version to C++17 or isolate FreeImage to use C++17. After all FreeImage has a C API, which doesn't care about C++ version used.

IMO you should focus on fixing problems that need fixing, rather than fixing problems no one is having as of right now. If someone really needs that functionality on older C++ versions, then you can reopen that discussion when that time arrives.

[agruzdev]

Okay, I got your point and it is very reasonable.

Drop-in replacement is supposed to be on DLL level, so you can build it with a modern compiler and then use as dynamic library for older compilers (since there is C API functions).

Otherwise, if you want to rebuild everything with an older compiler you might get compilation errors when using up-to-date image format dependencies (libpng, libtiff, etc.). We get same "multiple C++ versions support" issue here... and for 3rdParty source code too.
And using the up-to-date image codecs is the main reason to replace the old vanilla FreeImage version by this one, in my understanding.

Though, I don't mind having an extra Cmake flag to disable any extra functinality I've added.
Just it would be better to have an abstract Cmake macro:

#ifdef FREEIMAGERE_EXTRA_FUNCTIONS

instead of the very specific condition

#if __cplusplus >= 201703L

So it can be also switched via Cmake gui...