Closed Agadoul closed 7 years ago
No problem.
There are already a few files in DevIL which require C++ compilation as they link with C++ libraries. It's a little moot on Visual Studio, as nobody actually uses the C compiler anyway, other than people writing device drivers. I think you have to jump through hoops to even use it.
Here are some notes on this I wrote to myself a few months back:
C vs C++
---------
I've just been trying to compile IL from source (using CMake on Linux), but have run into some issues.
There seems to be a little mixing of C and C++ within src-IL.
The offending formats are:
* `il_exr.cpp` (in order to use the openEXR libs, which is a C++ interface)
* `il_squish.cpp` (because libsquish is a C++ interface?)
* `il_utx.cpp` (no external library used, but a few C++-isms in the source)
* `il_nvidia.cpp` (the nvidia texture tools lib is a C++ interface)
First off, I'd say that I think it's important that DevIL continues to present a plain C interface to the world - there's a lot of C code out there. and there's nothing in the public API that justifies requiring C++.
That said, it seems insane for DevIL not to use the openEXR, libsquish and nvtt libraries, which means some C++ is needed. The solutions I can see are:
1. switch to compiling DevIL with C++ (which I guess is what happens already most of the time). I _think_ the resulting library can be used fine from C, as long as all the public interface functions are all declared as `extern "C". ([here's what wikipedia says about it](https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B#Linking_C_and_C.2B.2B_code))
2. write little shim libraries which hide away all the C++ and present C versions of ilLoadExr() which DevIL can statically link to.
When DevIL was started 16 years ago, I think the rationale was that there weren't a lot of good freely available C++ compilers out there. Times have obviously changed lots, and it's interesting getting back into this after being mostly away for 7 years.
Oh yeah, C++ support was shockingly bad for a decade or two there :- ) But even today there are still a lot of good reasons to keep the library in C ABI compatible (even if it's C++ behind the scenes). There are a lot of people and projects still using C (especially out there in Linux-land), and C is a great lowest-common-denominator for doing bindings for any other language.
I'll agree with having a C-style interface so that we can use it from other languages easily. I need to figure out what the best path forward to make it thread safe is (the whole binding process for images is pretty antiquated, I feel).
Thanks - I've merged it into my fork, which I'm using as sort of a staging zone for getting stuff into the main DentonW repo.