AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
March 2017

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2017.03.17 14:29 "TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 14:53 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 15:53 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 16:07 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 17:01 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 17:06 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 17:19 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Yakov Galka
2017.03.17 17:02 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 21:02 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by <rleigh@codelibre.net>
2017.03.17 21:08 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 22:23 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Roger Leigh
2017.03.17 22:40 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Paavo Helde
2017.03.17 23:03 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.18 10:53 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Yakov Galka

2017.03.17 22:23 "Re: 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