Re: #include <funcapi.h>

Heres an interesting hack I just thought of that works:

extern "C" {
	#include <postgres.h>
	#include <fmgr.h>
	#define using _using
	#define typeid _typeid
	#define typename _typename
	#include <funcapi.h>
	#undef using
	#undef typeid
	#undef typename

	#ifdef PG_MODULE_MAGIC
	PG_MODULE_MAGIC;
	#endif
};


Now there is no collision with the C++ keywords.


On 26/12/2010, at 5:14 PM, Craig Ringer wrote:

> On 12/26/2010 02:14 PM, Elliot Chance wrote:
> 
>> In file included from /usr/include/pgsql/server/access/heapam.h:21,
>>                  from /usr/include/pgsql/server/nodes/execnodes.h:18,
>>                  from /usr/include/pgsql/server/executor/execdesc.h:18,
>>                  from /usr/include/pgsql/server/executor/executor.h:17,
>>                  from /usr/include/pgsql/server/funcapi.h:21,
>>                  from xapian.cpp:4:
>> /usr/include/pgsql/server/nodes/primnodes.h:1155: error: expected unqualified-id before ‘using’
> 
> You've neglected to mention which version of Pg you're compiling against, so that line number means nothing. What's the offending line of code and the surrounding few lines in primnodes.h?
> 
> In any case, I think it's very likely the issue is a C/C++ incompatibility in the Pg headers. It fails for me in a different place using Pg 9.1git and g++ 4.5, complaining about the use of "private" as an identifier in fmgr.h, because it's a keyword in C++.
> 
> This is one of the many reasons you should keep any code that touches the postgres innards as pure C, and call into your C++ code via "extern C" functions. The Pg headers aren't really C++ safe. Neither is Pg's longjmp-based error handling, which really won't mix well with exceptions or with stack-based objects that have dtors.
> 
> --
> Craig Ringer