Re: 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

--
cpp-today.blogspot.com

It would be great. I'm working at the moment on porting integer operations
to unsigned types, and the code is essentially a small number of functions,
repeated for every combination of integer types.
In C++ it could be simply one single set of template functions. Less code;
less bugs.

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(at)momjian(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)momjian(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce(at)momjian(dot)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

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.

> I'm really not in favor of moving to C++ though, as the
> portability-vs-usefulness tradeoffs seem pretty unattractive there.

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 server has not got a
decent C++ compiler or two. Portability is only really a problem with a
subset of new C++11 features.

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(at)momjian(dot)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