Thread: C++ compiler
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?
Regards
Gaetano Mendola
<div dir="ltr">It would be great. I'm working at the moment on porting integer operations to unsigned types, and the codeis essentially a small number of functions, repeated for every combination of integer types.<div style="style"> In C++it could be simply one single set of template functions. Less code; less bugs.</div><div class="gmail_extra"><br /><br/><div class="gmail_quote"><br /></div></div></div>
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
On Thu, Jun 20, 2013 at 12:45:48PM +0800, Craig Ringer wrote: > 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. I think the big question is whether you can _control_ what C++ features are used, or whether you are perpetually instructing users what C++ features not to use. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 06/24/2013 04:59 PM, Bruce Momjian wrote: > > On Thu, Jun 20, 2013 at 12:45:48PM +0800, Craig Ringer wrote: >> 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. > > I think the big question is whether you can _control_ what C++ features > are used, or whether you are perpetually instructing users what C++ > features not to use. How is that different than us having to do the same with C? JD > -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc For my dreams of your image that blossoms a rose in the deeps of my heart. - W.B. Yeats
On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >> >> I think the big question is whether you can _control_ what C++ features >> are used, or whether you are perpetually instructing users what C++ >> features not to use. > > > How is that different than us having to do the same with C? Perhaps the size of C++ ?
On Mon, Jun 24, 2013 at 09:21:26PM -0300, Claudio Freire wrote: > On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > >> > >> I think the big question is whether you can _control_ what C++ features > >> are used, or whether you are perpetually instructing users what C++ > >> features not to use. > > > > > > How is that different than us having to do the same with C? > > > Perhaps the size of C++ ? Right. I don't think there are any C features we want to avoid; are there any? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 06/24/2013 05:37 PM, Bruce Momjian wrote: > > On Mon, Jun 24, 2013 at 09:21:26PM -0300, Claudio Freire wrote: >> On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >>>> >>>> I think the big question is whether you can _control_ what C++ features >>>> are used, or whether you are perpetually instructing users what C++ >>>> features not to use. >>> >>> >>> How is that different than us having to do the same with C? >> >> >> Perhaps the size of C++ ? > > Right. I don't think there are any C features we want to avoid; are > there any? Anything supported by C99 and not other versions I would say. However, my point is if done correctly we would state which features ahead of time we are willing to use and make them part of the developer faq? Sincerely, JD > -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc For my dreams of your image that blossoms a rose in the deeps of my heart. - W.B. Yeats
On 06/25/2013 09:38 AM, Joshua D. Drake wrote: > > On 06/24/2013 05:37 PM, Bruce Momjian wrote: >> >> On Mon, Jun 24, 2013 at 09:21:26PM -0300, Claudio Freire wrote: >>> On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake >>> <jd@commandprompt.com> wrote: >>>>> >>>>> I think the big question is whether you can _control_ what C++ >>>>> features >>>>> are used, or whether you are perpetually instructing users what C++ >>>>> features not to use. >>>> >>>> >>>> How is that different than us having to do the same with C? >>> >>> >>> Perhaps the size of C++ ? >> >> Right. I don't think there are any C features we want to avoid; are >> there any? > > Anything supported by C99 and not other versions I would say. However, > my point is if done correctly we would state which features ahead of > time we are willing to use and make them part of the developer faq? If C++ is seriously being considered, I'd take a look at: http://gcc.gnu.org/codingconventions.html http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml and look into a stylechecker that warns when it finds usage of inappropriate features. Possibly combined with a useful static checker. A useful starting point might be https://en.wikipedia.org/wiki/Cpplint. http://clang-analyzer.llvm.org/ may also be interesting, though it's more of a static analysis tool and less of a source code lint. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Mon, Jun 24, 2013 at 06:38:48PM -0700, Joshua D. Drake wrote: > > On 06/24/2013 05:37 PM, Bruce Momjian wrote: > > > >On Mon, Jun 24, 2013 at 09:21:26PM -0300, Claudio Freire wrote: > >>On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > >>>> > >>>>I think the big question is whether you can _control_ what C++ features > >>>>are used, or whether you are perpetually instructing users what C++ > >>>>features not to use. > >>> > >>> > >>>How is that different than us having to do the same with C? > >> > >> > >>Perhaps the size of C++ ? > > > >Right. I don't think there are any C features we want to avoid; are > >there any? > > Anything supported by C99 and not other versions I would say. > However, my point is if done correctly we would state which features > ahead of time we are willing to use and make them part of the > developer faq? Yes, that would be the best approach. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Tue, Jun 25, 2013 at 10:32:42AM +0800, Craig Ringer wrote: > > Anything supported by C99 and not other versions I would say. However, > > my point is if done correctly we would state which features ahead of > > time we are willing to use and make them part of the developer faq? > > If C++ is seriously being considered, I'd take a look at: > > http://gcc.gnu.org/codingconventions.html > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml > > and look into a stylechecker that warns when it finds usage of > inappropriate features. Possibly combined with a useful static checker. > > A useful starting point might be https://en.wikipedia.org/wiki/Cpplint. > > http://clang-analyzer.llvm.org/ may also be interesting, though it's > more of a static analysis tool and less of a source code lint. Yes, we would need something like that. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
> Right. I don't think there are any C features we want to avoid; are
> there any?
We're avoiding C99-and-later features that are not in C89, such as //
for comments, as well as more useful things. It might be time to
reconsider whether we should move the baseline portability requirement
up to C99. I'm really not in favor of moving to C++ though, as the
portability-vs-usefulness tradeoffs seem pretty unattractive there.
(Still :-(. Bjorn should've frozen that language twenty years ago,
but he completely blew it as far as stability goes.)
regards, tom lane
<div class="moz-cite-prefix">On 25/06/2013 05:16, Tom Lane wrote:<br /></div><blockquote cite="mid:29207.1372133763@sss.pgh.pa.us"type="cite"><div class="moz-text-plain" graphical-quote="true" lang="x-western"style="font-family: -moz-fixed; font-size: 14px;" wrap="true">It might be time to reconsider whether we shouldmove the baseline portability requirement up to C99.</div></blockquote><br /> My understanding was that you pickedup a lot of users when the Win32 port became useful. While you can build with msys, I would think that leaving Microsoft'stooling behind would be a mistake, and as far as I am aware they have said that they are supporting C++11 butnot bothering with C99.<br /><br /><blockquote cite="mid:29207.1372133763@sss.pgh.pa.us" type="cite"><div class="moz-text-plain"graphical-quote="true" lang="x-western" style="font-family: -moz-fixed; font-size: 14px;" wrap="true">I'm really not in favor of moving to C++ though, as the portability-vs-usefulness tradeoffs seem pretty unattractivethere.</div></blockquote><br /> As a long-time C++ programmer I don't see what the problem would be beyond (some)existing contributors being wary of the unknown. Its not as if any platform developed enough to be a sane db serverhas not got a decent C++ compiler or two. Portability is only really a problem with a subset of new C++11 features.<br/><br />
On 06/25/2013 01:36 PM, james wrote: > On 25/06/2013 05:16, Tom Lane wrote: >> It might be time to reconsider whether we should move the baseline >> portability requirement up to C99. > > My understanding was that you picked up a lot of users when the Win32 > port became useful. While you can build with msys, I would think that > leaving Microsoft's tooling behind would be a mistake, and as far as I > am aware they have said that they are supporting C++11 but not bothering > with C99. In practice, a lot of what we'd want from C99 is part of C++11 (and older) anyway. If MSVC will permit the use of such features in C where they correspond to similar features in C++ then that'd be OK. Otherwise I guess it'd be another reason to give in and move to a C++ subset. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 06/24/2013 09:16 PM, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: >> Right. I don't think there are any C features we want to avoid; are >> there any? > > We're avoiding C99-and-later features that are not in C89, such as // > for comments, as well as more useful things. It might be time to > reconsider whether we should move the baseline portability requirement > up to C99. The problem here is we lose the MS compilers which are not being updated for C99. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc For my dreams of your image that blossoms a rose in the deeps of my heart. - W.B. Yeats