Good afternoon, Speaking as a C++ dev on a cross-platform library as my day job (and a long-ago author of the dell1600n_net SANE driver) a word of caution: there is far more variation in the capabilities of C++ compilers than there is for C, for example MSVC is far more "forgiving" than gcc, and that's before you open the can of worms of C++-11 and beyond.
Not trying to put you off (I love C++ :-) ) but be aware you'll need to be careful to steer clear of newer features of the language. cheers, Jon On Sun, 2019-05-12 at 13:32 +0900, Olaf Meeuwissen wrote: > Hi Povilas, list, > > Seeing you assigned the MR referenced below to me, here goes ;-) > > # I was going to follow-up anyway but wanted to give other the chance > to > # chime in first. > > Povilas Kanapickas writes: > > > 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. > > > As a concrete example of what the proposal would entail I've opened > > this > > PR which moves genesys backend to C++: > > > > https://gitlab.com/sane-project/backends/merge_requests/61 > > > > Total PR excluding generated files and spaces is only ~55 lines: > > around > > 40 lines of extern "C" definitions in the internal headers and 15 > > lines > > of changed code in the build system. > > I'll follow up with review comments in the MR itself. > > > 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. > > Think of what your LibreOffice users will say when an uncaught > exception > takes their unsaved document(s) with it :-O > > # The SANE backend I referenced above tries to give C++ SANE > frontends > # a fighting chance by calling `std::terminate()`. > > > - using simple C++ idioms to automatically free memory on function > > exit. This would essentially eliminate 95% of potential sources of > > memory leaks in the backend. I've just fixed one recently, so it's > > indeed an issue. > > ACK. Memory management in C++ is a lot less hassle, compared to C, > assuming you use RAII consistently for any custom types. > > 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/dona > te > Join the Free Software Foundation https://my.fsf.org/jo > in > -- 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]
