-
2017.03.17 14:53 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
-
2017.03.17 15:53 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
- 2017.03.17 16:07 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
- 2017.03.17 17:02 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
-
2017.03.17 15:53 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 22:23 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Roger Leigh
On 17/03/2017 21:08, Bob Friesenhahn wrote:
On Fri, 17 Mar 2017, rleigh@codelibre.net wrote:
Could I suggest a perhaps controversial but useful solution for handling errors, which might be worth your consideration.
If the libtiff core were to use a C++ TIFF class reporting errors via exceptions, it would be possible for this to be wrapped by the existing C API calling the C++ code in a try/catch block and reporting any thrown errors via the handlers. Or direct use by C++ code without any of that
Unfortunately, throwing C++ exceptions through C code is not portable. It would require that the using program to be linked using the C++ compiler. The built library would only support one C++ compiler (perhaps just one of several C++ dialects supported by the same compiler) due to C++ compiler run-time libraries and name mangling.
I like C++ but libtiff needs to remain a plain C library.
Note I'm not suggesting that exceptions be thrown through C code; if the C++ code is wrapped by 'extern "C"' functions, these could catch and handle the exceptions internally. This is the approach taken by e.g. the Mesa OpenGL implementation which has a C ABI but uses C++ internally.
If a C++ ABI was exposed, it would introduce additional linking requirements if static. That's something which could be done as a separate step though--if used internally without using the C++ standard library, it should be completely self-contained and could have an identical ABI to the existing implementation.
Keeping libtiff as a plain C library is of course a fine direction; I just wanted to mention this as a potentially beneficial direction which could be taken, particularly if you wanted to cater for better usage from C++ with regard to error handling, and also things like type-safe field access.
Regards,
Roger