Added to TODO: Allow C++ code to more easily access backend code
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php --------------------------------------------------------------------------- Kurt Harriman wrote: > > 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 > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers