Limbic~Region has asked for the wisdom of the Perl Monks concerning the following question:

All,
I am attempting to write some code that uses IBM's Global Name Recognition software. Unfortunately, they do not have a perl API though creating one shouldn't be that difficult. From the latest release notes:

The C++ interface to IBM NameWorks is now public. The C++ APIs are the definitive versions of the IBM NameWorks APIs, whereas the Java APIs are a thin, generally transparent “wrapper” layer over the C++ interface. The following example illustrates the differences between the C++ and Java versions of the analyzeForSearch() API:

C++: vector<QueryName> qnames; scoring.analyzeForSearch(name, 70, qnames);

Java: List<QueryName> qnames = scoring.analyzeForSearch(name, 70);

Other wrappers can be created for the C++ layer, such as managed C# for .NET, Ruby extensions, PHP extensions, or Perl extensions.

Now for some embarassing disclaimers.

What would be ideal is a full working example of what I ultimately need to duplicate. In my head, the process looks like this:

  1. Write a small C++ program that uses an external library that returns a non-trivial object
  2. Convert that stand alone program into Inline::CPP
  3. Call the function from perl and manipulate the returned object (as a hash?) in perl land

Any help or insight is appreciated. While I am not opposed to trudging through lots of documentation, I would prefer to have a working example to start from to be able to distinguish between problems in my understanding from those in my code.

Update 2010-03-17: I will very likely turn this into a pipe line process given the responses below. I happen to work with a former C++ developer so I will have him create me a stand-alone executable. Perl will generate a file of records as output. The C++ app will run the records through the APIs I need and write an output file which I will pick back up with perl on the other end. Not ideal but it gets the job done. Thanks!

Cheers - L~R

  • Comment on More Than A Little Help With Inline:CPP

Replies are listed 'Best First'.
Re: More Than A Little Help With Inline:CPP
by almut (Canon) on Mar 16, 2010 at 23:02 UTC

    I think one of the biggest challenges will be handling the C++ templates (like the vector in the sample you've shown).

    Inline::CPP doesn't seem to support them at all, and writing the XS code yourself that can handle them for non-trivial data structures will probably take some time to get familiar with (in particular considering your "disclaimers").

    You could try Swig, which claims to support templates — but I must say that when I personally had tried a project with Swig some time ago, my experiences with complex (and in particular dynamic) data structures were not the best, even though I didn't have to deal with templates... (after things had turned into a non-debuggable chaos, I eventually switched to plain XS, and things became a lot easier). That was about a decade ago, though, so I'm not sure in what ways Swig might have improved (I haven't used it since then).  Good luck, anyhow.

[reply]
[d/l]
Re: More Than A Little Help With Inline:CPP
by syphilis (Archbishop) on Mar 17, 2010 at 04:32 UTC
    Be aware that, although Inline::CPP is basically in good shape, it is currently unmaintained (as has been the case for quite some time). So check the bug reports.

    There's also a problem when using ParseRecDescent-1.96.0 with Inline::CPP. I don't know whether subsequent versions of Parse::RecDescent suffer the same problem - I do know that version 1.94 is fine.

    You probably already know that making the library and its headers visible to the compilation process is achieved in the same way as is done with Inline::C: 
    use Inline CPP => Config =>
    INC => '-I/path/to/include',
    LIBS => '-L/path/to/lib -lmylib';

    [download]
    That's about the sum of my knowledge of Inline::CPP. I have used it to successfully access a C++ library, but have done so by running only void functions that print output to the console. I haven't actually passed any objects around between perl and the library.

    Cheers,
    Rob
    Update: Changed "maintained" to "unmaintained". Thanks ikegami.
[reply]
[d/l]

Back to Seekers of Perl Wisdom