From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Gaetano Mendola <mendola(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: C++ compiler |
Date: | 2013-06-20 04:45:48 |
Message-ID: | 51C288FC.7090806@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2013-06-20 04:52:18 | Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements |
Previous Message | Amit Kapila | 2013-06-20 04:18:28 | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |