Two questions

Alastair David Reid reid at cs.utah.edu
Wed Aug 29 20:17:52 EDT 2001


D Tweed <tweed at cs.bris.ac.uk> writes:
>>> Other than being inelegant, is there anything to prevent me
>>> trying to hack on a stage in the foreign code interface stuff
>>> that compares the output of `nm' and `nm --demangle' [...]

Alastair wrote:
>> I don't see a fundamental problem - but it does sound like one of
>> those projects that is always 90% complete because the last 10% is
>> too painful to do properly.

D Tweed <tweed at cs.bris.ac.uk> replied:
> I'm a bit puzzled here: [explanation of why it's simple deleted]

I guess it was more of a metacomment.

This sounds like the kind of little hack which succeeds so well in its
narrow domain that you find yourself extending it to do a little bit
more.  This too succeeds but increases the demands a bit more...  And
before you know it, the whole thing has grown out of control but, for
the new domain that it has grown into, it really isn't very good at
all.

Personally, I'd use GreenCard (but compile the code with C++) for this
part of the project.  For the function you describe:

  result blockMatchScore16x16Simple(int *, int, int, int, unsigned char *, unsigned char *)

all you'd have to write is:

  %#include "some_header.hh"

  %fun blockMatchScore16x16Simple :: Int* -> Int -> Int -> Int -> Char* -> Char* -> Result

[I've written Int* and Char* instead of a more appropriate type
because I can't tell if those are in or out functions or arrays or ...
Fortunately, GreenCard deals well with these cases - you just write a
little bit more to disambiguate.]

No messing around with object files and the C++ compiler checks the types
of everything you write.

[If you really want to explore the object file route, I can offer you
a program to rename symbols in ELF files :-)  It's a very small part of
Knit which you can get by following the links to my current project in
my web page.]


> To be more concrete what I'd like to be able to do without too much work
> setting up each new case is
> 
>      C++ ----------> Haskell
>                          |
>      C++ function <------

Ah, I hadn't appreciated that you wanted to do a lot of calling in
from C++.  Greencard can do Haskell -> C/C++ but offers no support for
the other direction.  (Probably because the dynamic linking required 
in Hugs would be ugly.)

Seems like the more recent C<->Haskell tools ought to be of some use.

Of course, the function names will need mangled somehow.
Apart from using ugly names in the Haskell code, options include:

1) Use your nm | grep | ... trick

2) If using Hugs' ffi implementation (not strongly recommended),
   try compiling the code Hugs generates with a C++ compiler.
   It might just work...

3) Use my object file renamer

-- 
Alastair Reid        reid at cs.utah.edu        http://www.cs.utah.edu/~reid/




More information about the FFI mailing list