Re: SPI-header-files safe for C++-compiler
| От | Jacob Rief |
|---|---|
| Тема | Re: SPI-header-files safe for C++-compiler |
| Дата | |
| Msg-id | 20070629093459.38870@gmx.net обсуждение исходный текст |
| Ответ на | Re: SPI-header-files safe for C++-compiler (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: SPI-header-files safe for C++-compiler
|
| Список | pgsql-patches |
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.
> not see the point of fixing it from our side unless we are prepared to
> buy into a lot of other changes. A C++ writer who is unwilling to add
> the extern{} bit around inclusions of C headers seems unlikely to "work
> with us" as regards to error-throwing conventions, for instance.
I would have never posted any patch, if just adding extern "C" { } would
have solved my problems, but as mentioned above, it doesn't.
Jacob
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
В списке pgsql-patches по дате отправления: