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

"Chuck McDevitt" <cmcdevitt@greenplum.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