Re: SPI-header-files safe for C++-compiler
От | Marko Kreen |
---|---|
Тема | Re: SPI-header-files safe for C++-compiler |
Дата | |
Msg-id | e51f66da0706290302w2bbea43ds1820ce8f6541297d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SPI-header-files safe for C++-compiler ("Jacob Rief" <jacob.rief@gmx.at>) |
Список | 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 по дате отправления: