[sane-devel] Using C++ in sane backends
jon at jon.demon.co.uk
Sun May 12 12:49:21 BST 2019
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.
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
> # 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
> than C. All the SANE API specification requires is that SANE
> provide a certain C API. What a backend does "under the covers" is
> backends business.
> I have implemented a third party SANE backend in C++ myself. See
> Whether we want to allow C++ in the SANE Project's sane-backends (and
> 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*
> 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
> no chance of saving state.
> Think of what your LibreOffice users will say when an uncaught
> takes their unsaved document(s) with it :-O
> # The SANE backend I referenced above tries to give C++ SANE
> # 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-
> GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A
> Support Free Software https://my.fsf.org/dona
> Join the Free Software Foundation https://my.fsf.org/jo
More information about the sane-devel