"Chuck McDevitt" <[EMAIL PROTECTED]> 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


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

(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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to