Re: SPI-header-files safe for C++-compiler - Mailing list pgsql-patches

> Neil Conway <neilc@samurai.com> writes:
> > I don't see a reason to reject the patch. All the arguments about
why
> > using C++ in the backend is ill-advised are well-taken, but the
patch
> > does *not* require "making a real commitment to making C++ usable as
> a
> > backend extension language", it just obviates the need for some
> people
> > to patch the source.
>
> ... at the cost of forcing other people to patch their source.  If
this
> were just an internal backend change it'd be OK, but by definition the
> patch is changing APIs that third-party code may depend on.  That's
why
> I think there needs to be a stronger argument than "might as well do
> it", and that stronger argument has got to discuss whether we are
> really
> supporting C++ in the backend.
>
> There's also a slippery-slope problem: if we accept making these
> headers
> C++-clean, why not every other backend header?  Once we buy into the
> principle, you can bet that we'll get requests to sanitize every
header
> that's of any interest.  So I'd want to see some estimate of how many
> changes that entails, not just fixing the set of things that spi.h
> depends on.
>
>             regards, tom lane
>

I've tried compiling the entire backend in C++ in the past, just to see
how much of a problem it would be.

The effort to fix the header files is minimal, just a few global
search-and-replace operations for C++ keywords such as "typename",
"typeid", "namespace" and "using", and doing the appropriate stuff to
use the native C++ bool, true, and false.
After that, it's mostly a matter of changing places that rely on
implicit casts from void * to add explicit casts.  One day of effort at
most.

So, the programmer effort is quite small, but it does change quite a few
.c files (especially "typename").

And in the end, you can't actually run full C++ code unless you do
something about the setjmp longjmp (TRY() etc), as they are incompatible
with C++ destructors, although you could use C++ if you avoided
constructors/destructors/try-catch/etc.

Here is what I think is a complete list of C++ keywords not in C (most
are not using in Postgres):

asm         dynamic_cast  namespace  reinterpret_cast  try
bool        explicit      new        static_cast       typeid
catch       false         operator   template          typename
class       friend        private    this              using
const_cast  inline        public     throw             virtual
delete      mutable       protected  true              wchar_t

Overall, I'm in favor of the change.
I don't think the effort to "sanitize" all the headers is difficult at
all.