Re: [GENERAL] C++ port of Postgres - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [GENERAL] C++ port of Postgres
Date
Msg-id bf9de63c-b669-4b8c-d33b-4a5ed11cd5d4@2ndquadrant.com
Whole thread Raw
In response to Re: [GENERAL] C++ port of Postgres  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: [GENERAL] C++ port of Postgres  (Christian Convey <christian.convey@gmail.com>)
Re: [GENERAL] C++ port of Postgres  (Heikki Linnakangas <hlinnaka@iki.fi>)
Re: [GENERAL] C++ port of Postgres  (Christian Convey <christian.convey@gmail.com>)
Re: [GENERAL] C++ port of Postgres  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
[trimmed cc list because of big attachments]

On 8/16/16 4:22 PM, Jim Nasby wrote:
> Joy, do you have an idea what a *minimally invasive* patch for C++
> support would look like? That's certainly the first step here.

I developed a minimally invasive patch for C++ support a few years ago
shortly after I wrote that blog post.  Since there appears to have been
some interest here now, I have updated that and split it up into logical
chunks.

So here you go.

To build this, you need to configure with g++ <= version 5.  (4.x works,
too.)  g++ version 6 does not work yet because of the issues described
in patch 0013.

Then you also need to edit src/Makefile.custom and set

    COPT = -fpermissive -Wno-sign-compare -Wno-write-strings

The -W options are optional just to reduce some noise.  Cleaning up
those warnings can be a separate project that might also have some
benefit under C.

The -fpermissive option is a g++ specific option that reduces some
errors to warnings.  (So this won't work with clang or other compilers
at all at this point.)  In particular, C++ does not allow casting from
or to void pointers without a cast, but -fpermissive allows that.  The
step from this to "real" C++ would be adding a bunch of casts around
things like malloc and palloc and other places.  That would be mostly
busy work, so I have excluded that here.

The patches are numbered approximately in increasing order of dubiosity.
 So 0001 is probably a straight bug fix, 0002 and 0003 are arguably
minor bug fixes as well.  The patches through 0012 can probably be
considered for committing in some form.  After that it gets a bit hackish.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Ivan Kartyshov
Date:
Subject: less expensive pg_buffercache on big shmem
Next
From: Tom Lane
Date:
Subject: Re: Missing checks when malloc returns NULL...