Bruce Momjian wrote:
> Peter Geoghegan wrote:
> > >> I would have
> > >> imagined that ultimately, the call to the Pg C function must return,
> > >> and therefore cannot affect stack unwinding within the C++ part of the
> > >> program.
> > >
> > > That's the whole point; a longjmp breaks the call c
David Fetter wrote:
It's good to have actual working code in production to bolster the
case that the design is sound.
How much work would it be to refactor libgeos_c to use a catch-all
exception handler?
Cheers,
David.
Given that GEOS is not used exclusively by PostGIS but also by quite a
f
> It's good to have actual working code in production to bolster the
> case that the design is sound.
>
> How much work would it be to refactor libgeos_c to use a catch-all
> exception handler?
>
Well, they'd have to be using specific exception handlers to get the
error message. Perhaps they just
Hi Mark. You'll recall that I talked with you for quite a while at
Pg-day 2009 in Paris. Nice of you to chime in here.
> Except that Pg, via palloc, offers a way to clean up a whole memory context.
> Ensuring you delete your C++ object graph (probably via a few opaque
> pointers you pass around i
Peter Geoghegan wrote:
> >> I would have
> >> imagined that ultimately, the call to the Pg C function must return,
> >> and therefore cannot affect stack unwinding within the C++ part of the
> >> program.
> >
> > That's the whole point; a longjmp breaks the call chain, and the
> > guarantee that ev
On Wed, Jun 02, 2010 at 05:41:10PM +0100, Mark Cave-Ayland wrote:
> David Fetter wrote:
>
> >Is PostGIS following these guidelines?
>
> In short, no. Due to various problems in the early days with C++
> exceptions generated by the GEOS library causing problems in C (and
> also ABI changes forcing
David Fetter wrote:
Is PostGIS following these guidelines?
In short, no. Due to various problems in the early days with C++
exceptions generated by the GEOS library causing problems in C (and also
ABI changes forcing a recompile of any GEOS linked library), a thin
intermediate C++ layer cal
On 2/06/2010 11:49 PM, Peter Geoghegan wrote:
On 2 June 2010 13:36, Craig Ringer wrote:
Really? That seems like an *incredibly* arduous requirement.
Intuitively, I find it difficult to believe. After all, even though
using longjmp in C++ code is a fast track to undefined behaviour, I
would hav
On 2 June 2010 13:36, Craig Ringer wrote:
>>
>> Really? That seems like an *incredibly* arduous requirement.
>> Intuitively, I find it difficult to believe. After all, even though
>> using longjmp in C++ code is a fast track to undefined behaviour, I
>> would have imagined that doing so in an isol
Craig Ringer wrote:
> See the attached demo (pop all files in the same directory then run "make").
>
>
> > I would have
> > imagined that ultimately, the call to the Pg C function must return,
> > and therefore cannot affect stack unwinding within the C++ part of the
> > program.
>
> That's the
On Wed, Jun 02, 2010 at 10:11:37AM +0800, Craig Ringer wrote:
> On 02/06/10 09:23, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Craig Ringer writes:
> >>> On 01/06/10 11:05, Tom Lane wrote:
> I'd be interested to see a section like this written by someone who'd
> actually done a nontriv
On 02/06/10 19:17, Peter Geoghegan wrote:
>> Similarly, calling Pg code that may use Pg's error handling from within
>> C++ is unsafe. It should be OK if you know for absolute certain that the
>> C++ call tree in question only has plain-old-data (POD) structs and
>> simple variables on the stack,
> Letting an exception thrown from C++ code cross into C code will be
> EXTREMELY ugly. The C++-to-C boundaries *must* have unconditional catch
> blocks to convert thrown exceptions into appropriate error codes, even
> if the C++ code in question never knowingly throws an exception. C++ may
> throw
Craig Ringer wrote:
> ( BTW, all in all, I agree with Tom Lane - the best answer is "don't".
> Sometimes you need to access functionality from C++ libraries, but
> unless that's your reason I wouldn't ever consider doing it. )
>
> Here's a rough outline of the rules I follow when mixing C/C++ code
On 02/06/10 09:23, Bruce Momjian wrote:
> Tom Lane wrote:
>> Craig Ringer writes:
>>> On 01/06/10 11:05, Tom Lane wrote:
I'd be interested to see a section like this written by someone who'd
actually done a nontrivial C++ extension and lived to tell the tale.
>>
>>> I can't speak up ther
Tom Lane wrote:
> Craig Ringer writes:
> > On 01/06/10 11:05, Tom Lane wrote:
> >> I'd be interested to see a section like this written by someone who'd
> >> actually done a nontrivial C++ extension and lived to tell the tale.
>
> > I can't speak up there - my own C++/Pg backend stuff has been fa
Craig Ringer writes:
> On 01/06/10 11:05, Tom Lane wrote:
>> I'd be interested to see a section like this written by someone who'd
>> actually done a nontrivial C++ extension and lived to tell the tale.
> I can't speak up there - my own C++/Pg backend stuff has been fairly
> trivial, and has been
On Tue, Jun 01, 2010 at 02:13:02PM +0800, Craig Ringer wrote:
> On 01/06/10 11:05, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Tom Lane wrote:
> >>> Personally I would reduce this section to
> >>> Don't.
> >
> >> Well, I would have avoided this mine-trap except we have this 9.0
> >> release
On 01/06/10 11:05, Tom Lane wrote:
> Bruce Momjian writes:
>> Tom Lane wrote:
>>> Personally I would reduce this section to
>>> Don't.
>
>> Well, I would have avoided this mine-trap except we have this 9.0
>> release note item:
>>Allow use of C++ functions in backend code (Kurt
>>
On 01/06/10 10:48, Tom Lane wrote:
Too bad two out of the four pieces of advice are wrong (how many pieces
of memory managed by the backend are allocated directly with malloc?).
The other two are not wrong as far as they go, but they're certainly
woefully inadequate, because no interesting backe
Tom Lane wrote:
> Bruce Momjian writes:
> >>> Well, I would have avoided this mine-trap except we have this 9.0
> >>> release note item:
> >>> Allow use of C++ functions in backend code (Kurt
> >>> Harriman, Peter Eisentraut)
>
> > So should I just comment it out and then when someone gets se
Bruce Momjian writes:
>>> Well, I would have avoided this mine-trap except we have this 9.0
>>> release note item:
>>> Allow use of C++ functions in backend code (Kurt
>>> Harriman, Peter Eisentraut)
> So should I just comment it out and then when someone gets serious we
> can use it as a
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Personally I would reduce this section to
> >>Don't.
>
> > Well, I would have avoided this mine-trap except we have this 9.0
> > release note item:
> >Allow use of C++ functions in backend code (Kurt
> >Harriman,
Bruce Momjian writes:
> Tom Lane wrote:
>> Personally I would reduce this section to
>> Don't.
> Well, I would have avoided this mine-trap except we have this 9.0
> release note item:
>Allow use of C++ functions in backend code (Kurt
>Harriman, Peter Eisentraut)
I'd be inter
Tom Lane wrote:
> Bruce Momjian writes:
> > That is great new information. I have created a new documentation
> > section called "Using C++ for Extensibility", and listed you as the
> > author in the CVS commit; patch attached. Thanks.
>
> Too bad two out of the four pieces of advice are wron
Bruce Momjian writes:
> That is great new information. I have created a new documentation
> section called "Using C++ for Extensibility", and listed you as the
> author in the CVS commit; patch attached. Thanks.
Too bad two out of the four pieces of advice are wrong (how many pieces
of memory
Craig Ringer wrote:
> Igor wrote:
> > Hi All,
> >
> > Is there an easy way to add c++ files to my simple pgsql module ? My
> > Makefile
> > is as follows -
> >
> > ===
> > MODULES = pg_uservars
> > DATA_built = pg_uservars.sql
> > PGXS := $(shell pg_config --pgxs)
> > include $(PGXS)
> > ===
>
Igor wrote:
> Hi All,
>
> Is there an easy way to add c++ files to my simple pgsql module ? My Makefile
> is as follows -
>
> ===
> MODULES = pg_uservars
> DATA_built = pg_uservars.sql
> PGXS := $(shell pg_config --pgxs)
> include $(PGXS)
> ===
>
> I've got "pg_uservars.c" and "hv.cc" and I'd
Hi All,
Is there an easy way to add c++ files to my simple pgsql module ? My Makefile
is as follows -
===
MODULES = pg_uservars
DATA_built = pg_uservars.sql
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
===
I've got "pg_uservars.c" and "hv.cc" and I'd like to compile hv.cc via g++.
I'm aw
29 matches
Mail list logo
