Re: C++ compiler - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: C++ compiler
Date
Msg-id 51C288FC.7090806@2ndquadrant.com
Whole thread Raw
In response to C++ compiler  (Gaetano Mendola <mendola@gmail.com>)
Responses Re: C++ compiler
List pgsql-hackers
On 06/16/2013 03:19 AM, Gaetano Mendola wrote:
> I have read Peter Eisentraut blog entry about "Moving to C++", I full agree
> with him about what he wrote.
>
> Is there any interest or work in progress in making the entire Postgresql
> code base compilable by a C++ compiler?
Well, from Peter at least, clearly ;-)

Personally I'd find it useful - I'm used to working with
C-compiled-as-C++ and find the things the C compiler will pass without
warning or mention to be astonishing. The C++ compiler, even when being
used to build programs that are entirely 'extern "C" ', provides
significantly more useful static checking than the C compiler, but
nothing like a proper static checker.

PostgreSQL wouldn't play well with idiomatic C++, given its heavy use of
longjmp() based exception handling; that doesn't play at all well with
C++'s expectation that it can unwind the stack when a C++ exception
occurs. It'd have to compile with -fno-exceptions (or equivalent in
MSVC) - and because of that, would have to be very careful if any 3rd
party C++ libraries were used. That just reinforces the idea that using
the C++ compiler as a better C compiler would be the way to go.

Though, given the presence of PG_TRY etc, I'd want to see just what
would be involved in using C++ exceptions. If nothing else, I'd have fun
re-defining PG_TRY and PG_CATCH to use C++ exceptions, then watching the
fireworks. A read of the elog/ereport functions shows that they're
significantly different to C++ exception handling, particularly where it
comes to things like the logic for promoting errors in certain
situations (FATAL->PANIC during a critical section, etc).

Anyway, what astonished me when I looked at the post was the assumption
from so many that it'd be better to *re-write* in C++. Was nothing
learned from the Mozilla fiasco? Even if the PostgreSQL codebase were in
a truly shocking state - and it certainly isn't! - it would probably
make very little sense to rewrite. Well, not if you wanted to have
anything usable for the next 10-15 years.

I see value in making the codebase compileable with g++... and down the
track I can see being able to use basic class features as quite useful
given Pg's fairly OO internal design. Inline template functions instead
of macros would be nice. I've worked with C++ enough not to be overly
excited by the idea of going down the rabbit hole of Boost, complex
template arrangements, etc, and I don't love the STL ... but any
sensible project adopting C++ carefully picks and chooses what features
it uses and how.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Next
From: Amit Langote
Date:
Subject: Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements