From: | "Chuck McDevitt" <cmcdevitt(at)greenplum(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Neil Conway" <neilc(at)samurai(dot)com> |
Cc: | "Jacob Rief" <jacob(dot)rief(at)gmx(dot)at>, pgsql-patches(at)postgresql(dot)org, andrew(at)dunslane(dot)net |
Subject: | Re: SPI-header-files safe for C++-compiler |
Date: | 2007-07-01 18:24:14 |
Message-ID: | EB48EBF3B239E948AC1E3F3780CF8F880244ECC2@MI8NYCMAIL02.Mi8.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
> Neil Conway <neilc(at)samurai(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-07-01 18:24:32 | Re: dblink connection security |
Previous Message | Tom Lane | 2007-07-01 18:08:58 | Re: dblink connection security |