Re: C++ compiler
От | Craig Ringer |
---|---|
Тема | Re: C++ compiler |
Дата | |
Msg-id | 51C288FC.7090806@2ndquadrant.com обсуждение исходный текст |
Ответ на | C++ compiler (Gaetano Mendola <mendola@gmail.com>) |
Ответы |
Re: C++ compiler
|
Список | 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 по дате отправления: