Re: SPI-header-files safe for C++-compiler

"Chuck McDevitt" <cmcdevitt(at)greenplum(dot)com> writes:
> I've tried compiling the entire backend in C++ in the past, just to see
> how much of a problem it would be.

Just for fun, I tried that experiment tonight on CVS HEAD: I used g++
from a current Fedora 6 installation (g++ Red Hat 4.1.1-51) instead of
the usual C compiler. It appears that the OP's patch is nearly complete
in terms of struct fields that'd have to be renamed: I find

src/include/nodes/memnodes.h:
MemoryContextMethods.delete
src/include/nodes/parsenodes.h:
TypeName.typeid
A_Const.typename
TypeCast.typename
ColumnDef.typename
XmlSerialize.typename
AlterDomainStmt.typename
CreateDomainStmt.typename
CreateEnumStmt.typename
src/include/nodes/primnodes.h:
JoinExpr.using

and it's reasonably arguable that none of these are very likely to be
referenced directly by third-party code; certainly not so likely as to
pose a bigger cross-version-compatibility problem than we routinely
create.

(I did not get as far as the PLs or contrib/, but those are even less
likely to be exporting anything that outside code would depend on.)

The problem that I see after trying the experiment, however, is that
actually building Postgres using a C++ compiler would require changes
enormously more invasive than just renaming some fields and function
argument names. And I have no confidence in our ability to *keep* the
headers C++-clean if there's not a buildfarm member out there building
it with a C++ compiler so it can gripe about re-introduction of C++
keywords. So I'm afraid the issue will just keep coming back.

Chuck mentioned the point that C++ rejects implicit casts from void*
to something else, but there are a lot of other problems, including
some that would require notational compromises I don't think we'd like
to make. Two examples:

* g++ rejects struct assignment if either source or destination is
accessed through a volatile pointer. We do that in a number of places,
mostly in xlog.c and bufmgr.c. Options I can see are not good:
1: don't use volatile (not acceptable)
2: cast away volatile (probably breaks the guarantee we want)
3: do the assignment explicitly field-by-field (sucks from a
maintenance point of view, not to mention legibility)
4: use memcpy (sucks for performance because structs are small,
and probably requires casting away volatile, see #2)

* I don't see how to make expression_tree_walker and
expression_tree_mutator work reasonably nicely; g++ is too picky about
the argument types of the walker/mutator function.

C++'s commandeering of "bool" might be an issue also; is it guaranteed
anywhere that that's the same size/alignment as "char"?

BTW, one problem I didn't understand at all was that g++ spit up on
bitand() and bitor() as function names. Those are not C++ keywords
to my knowledge; anyone have a theory?

Anyway, at this point my concern is not so much whether we could fix
it as what is the plan for keeping it fixed.

regards, tom lane