Re: SPI-header-files safe for C++-compiler - Mailing list pgsql-patches

From Marko Kreen
Subject Re: SPI-header-files safe for C++-compiler
Date
Msg-id e51f66da0706290302w2bbea43ds1820ce8f6541297d@mail.gmail.com
Whole thread Raw
In response to Re: SPI-header-files safe for C++-compiler  ("Jacob Rief" <jacob.rief@gmx.at>)
List pgsql-patches
On 6/29/07, Jacob Rief <jacob.rief@gmx.at> wrote:
> On Thu, 2007-28-06 at 01:15 -0400, Tom Lane wrote:
> > Sure, but we don't break them just on a whim.  The bottom line here is
> > whether we are going to make a real commitment to making C++ usable as
> > a backend extension language --- and for the reasons I mentioned, that
> > would entail a lot more than renaming a few identifiers.  It was already
> > pointed out upthread that wrapping the inclusions in extern "C" {...}
> > would fix the identifier part of the problem from the user side, so I do
>
> No, wrong. Adding extern "C" does not fix the C++-keywords as identifiers
> problem. Adding extern "C" only tells the compiler to switch off
> name-mangling. A C++-compiler does not allow any kind of plain-old C in
> such blocks. With some drawbacks, it is even perfectly legal to use some
> C++ features inside an extern "C" block.

I think you are better off wrpapping your C++ code to small
pure-C module and export only that to Postgres-interfacing
C code.  Thus you keep away making C++ seeing Postgres code.

It is really a mistake to think C as subset of C++.  They are
really different languages.  C-as-subset-of-C++ works only
with trivial C code.  If you have big, old, real-life codebase
like Postgres, it really does not pay off to force it to comply
with C++ rules.  Just to avoid the work of writing intermediate
wrapper code.

--
marko

pgsql-patches by date:

Previous
From: "Jacob Rief"
Date:
Subject: Re: SPI-header-files safe for C++-compiler
Next
From: Patrick Welche
Date:
Subject: Re: configure.in / xml / quoting trouble