Hi Povilas, list, Povilas Kanapickas writes:
> On 2019-05-12 07:32, Olaf Meeuwissen wrote>> On 2019-05-09 11:56, > Povilas Kanapickas wrote: >>>> I would propose we allow C++, but that its use must not affect API or >>>> ABI in any way. There should be a hard requirement that there must be no >>>> visible changes outside a specific backend, except the need to link the >>>> backend with libstdc++. >> >> Technologically, there is no reason why one cannot use another language >> than C. All the SANE API specification requires is that SANE backends >> provide a certain C API. What a backend does "under the covers" is that >> backends business. >> >> I have implemented a third party SANE backend in C++ myself. See >> >> https://gitlab.com/utsushi/utsushi/blob/master/sane/backend.cpp >> >> Whether we want to allow C++ in the SANE Project's sane-backends (and to >> what extent) is an issue that we need some consensus on, I think. > > Agreed. The reason why I thought that it would be possible to achieve > some consensus at all was that there's no consistent design of the > backends included within the sane-backends repository so they could be > considered separate projects within a monorepo. In that case using C++ > in one backend is not a problem as most SANE developers will not need to > interact with that code in any way. ACK. >>> Two benefits that would yield almost immediate improvements are the >>> following: >>> >>> - ability to use exceptions instead of manual error handling which >>> currently often explodes the amount of code by 4 times. >> >> I was "afraid" of this ;-) >> >> Please be aware that your backend will have to catch *all* exceptions, >> even the ones you don't throw yourself, e.g. an `std::bad_alloc`. Any >> uncaught exception will crash SANE frontends right then and there with >> no chance of saving state. > > Agreed. My plan was to catch all exceptions, print something to logs and > then return some error status code so that everything works just like if > the C implementation got an error it couldn't recover from. The caller > code should be completely isolated from what happens within the backend. Good plan but might be harder than you think. I had the same plan way back when I wrote that utsushi SANE backend and learnt the hard way. Especially the exception that was thrown *before* its sane_init() was even called had me bang my head against the wall for a while. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join -- sane-devel mailing list: [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to [email protected]
