[sane-devel] Using C++ in sane backends

[Jon Chambers]

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
>