Re: Calling c++ functions returning non-pod types

[Philip Ashmore <contact at philipashmore dot com>]

On 21/02/13 17:51, Andrew Haley wrote:
> On 02/21/2013 05:46 PM, Philip Ashmore wrote:
> > On 21/02/13 15:19, Andrew Haley wrote:
> > > On 02/21/2013 01:29 PM, Philip Ashmore wrote:
> > > > I think a better option would be to tell libffi that the return type is
> > > > a "non-pod" and let it jump the hoops appropriate for the architecture -
> > > > am I correct in guessing that my approach isn't portable?
> > >
> > > Sort of.  There is a standardish C++ ABI known for reasons too arcane to
> > > go into as the Itanium C++ ABI
> > > http://refspecs.linux-foundation.org/cxxabi-1.83.html
> > >
> > > However, putting all this stuff into libffi would be too much IMO.  You
> > > could think of defining a C++ layer that calls libffi.
> >
> > if only because libffi doesn't create temporaries for ignored return values.
> > I guess I'm going to have to define a portability layer myself then.
> >
> > Does/could libffi define macro I could use to determine the c++ ABI?
>
> Only the usual system defines.
>
> > The next thing I'd need is a page of docs for all the c++ ABIs for the c
> > ABIs that libffi supports.
> >
> > If you could reply with such a list that would be great - I'll push
> > ahead with the platform I'm on now - Debian sid amd64.
>
> All the Linuxen use the Itanium C++ ABI.  Do you care about Windows
> and BSD?
I don't know BSD and my projects won't run on Windows because of design 
choices, although I'd be happy if someone wanted to port my stuff onto 
them - I could merge the changes back in.

I'd like it if at some point my projects could run on all the platforms 
libffi supports, but that's some ways off.
> Andrew.
Philip