Skip site navigation (1) Skip section navigation (2)

Re: Calling C++ function

From: Richard Welty <rwelty(at)averillpark(dot)net>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Calling C++ function
Date: 2004-08-15 20:35:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
On Sun, 15 Aug 2004 14:27:38 -0400 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Oliver Archner <oliver(dot)archner(at)bitoek(dot)uni-bayreuth(dot)de> writes:
> > Can anyone point me to example which calls a C++ function from a dynamic 
> > library ?

> It's gonna be fairly painful, since the backend is a C program not a C++
> program, and therefore it does not provide any of the infrastructure
> that C++ code is likely to expect --- no exception stack, no global
> constructors/destructors, no C++ library, etc.  I am not sure how much
> of this is practical to load after-the-fact in a dynamic library.

it can probably be pulled off. it will probably be very annoying to do.
we used to call gnu C++ from a Lucid Common Lisp environment back
at GE R&D (i was responsible for that particular integration can of
worms, it brings back painful memories, and it probably was a major
factor in my continuing dislike for C++.)

the library loads and initialization are an issue, as is figuring out the
"C Name" of the C++ functions. we used to run nm over the C++ object
files to find out what the C++ name mangler did. it was very clumsy,
and i spent a lot of time wishing for a better method.

tom's suggestion of shelling out might be a lot less painful.

Richard Welty                                         rwelty(at)averillpark(dot)net
Averill Park Networking                                         518-573-7592
    Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security

In response to

pgsql-interfaces by date

Next:From: Sam StephensDate: 2004-08-16 10:22:00
Subject: C text to string issue
Previous:From: Tom LaneDate: 2004-08-15 19:02:10
Subject: Re: Type implemented in plpythonu crashes backend

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group