"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
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
---------------------------(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
