Re: Mostly Harmless: Welcoming our C++ friends - Mailing list pgsql-hackers

> Is there anything in the source that would necessarily preclude using the
> C++ compiler to build *all* the code?

No.  Most of the source files would need a sprinkling of
tiny changes: typically only a handful of casts need to be
added.  Some files would need more widespread (but still
trivial) changes, such as renaming local variables or
parameters which are C++ reserved words.  There are a few
head-scratchers: see this post  (1 July 2007)
http://groups.google.com/group/pgsql.patches/msg/91775dc1355cdc72
or http://tinyurl.com/6a67ms

I've actually gone through the tedious experiment of fixing up
about 40 of the source files so they can be compiled as either
C or C++.  With these files compiled as C++, and the remainder
compiled as C, PostgreSQL builds successfully and passes the
'make check' regression tests.  The intermixture of C together
with C-compiled-as-C++ works just fine, at least on my x86-32
Linux platform.  On the other hand, PostgreSQL already works
as C; trying to convert it all to C++ doesn't seem useful.

Suppose we were to use the C++ compiler to build all of
PostgreSQL.  Consider the alternatives:  either
  A) switch over entirely to C++, no longer supporting C; or
  B) let the build farm do a nightly build with a C++ compiler     merely as a test to verify that no C++ compilation
errors    are introduced, but continue to use C 'officially' for     builds and releases; or
 
  C) support C and C++ equally, allowing the choice to be made     by each person who builds PostgreSQL from source.

Alternative A breaks (almost?) all existing third party
extension code: sufficient reason to rule out this alternative.

With Alternative B, most development work would probably still
be done in C.  C programmers surely won't embrace the idea
that they should conform to C++ rules and take care that their
C code is C++-compilable.  Some of the C++ rules are obscure;
rare is the C++ programmer who never omits a needed cast.
Every patch will have to be checked for C++ compatibility.
If the build farm detects a C++ error, likely one of the
committers would be saddled with the burden of backing
out the patch and/or correcting the error.

Alternative C seems to just about double the amount of work
involved in every commit, build, and release.  Again, much
of the burden probably falls on the committers.

All the extra work and trouble will be justified if there is
a truly spectacular payoff.  What magnificence awaits us when
all of PostgreSQL is C++-compilable?  I don't have a good
answer.

The best alternative, in my opinion, is "none of the above".
That's why I have instead offered some patches to enable C++
for new extensions and add-on development with minimal
impact to the C core.

As a courteous host, one might extend hospitality to a guest,
but not indeed go so far as to redecorate the house from top
to bottom to suit the guest's taste.

Regards,
... kurt

James Mansion wrote:
> Is there anything in the source that would necessarily preclude using the
> C++ compiler to build *all* the code?
> 
> I'd guess that this would be quite a big patch to do this in any places
> where we have implicit conversions from void* to char* etc, but
> the result is valid as C and C++ and arguably better documented.
> 
> C++ is picky about a few things you can do in C, but most of them
> are things I'd rather not do anyway.
> 
> Run such a build on the build farm each night, and it will be obvious as
> soon as C++-unfriendly code sneaks in.
> 
> And who know, maybe eventually we could use C++ properly in the
> code.
> 
> James