How hard is it to develop XOPs (when you already have some C/C++ experience)?

Share icon

I have a potential opening to work in a collaboration with a colleague who is versed in C/C++ programming using Borlands C++ Builder Environment. He has asked me two questions that, in my ignorance, I admittedly have no background to answer. I have two additional questions to add to the list.

* Does the Igor Pro XOP Toolkit support this compiler?
* Will the compiled code be as fast as what he has developed on his own (with multi-threading support)?
* What additional effort is needed to convert self-developed C/C++ code to an XOP (i.e. is it a "nuke and repave" effort or a "tweak around the edges" effort)?
* What additional effort is needed to create a Mac-based XOP along with the Windows-based XOP?

I would appreciate comments and insights from folks who know how to develop XOPs.

Thanks!
Quote:
Does the Igor Pro XOP Toolkit support this compiler?


It does not support Borland. It does support MS Visual C++ and Apple's Xcode. An experienced programmer could probably make it work in Borland as the XOP Toolkit is a library like thousands of others.

Quote:
Will the compiled code be as fast as what he has developed on his own (with multi-threading support)?


An XOP is a DLL written in C or C++ code and works like any other DLL written in C or C++.

Quote:
What additional effort is needed to convert self-developed C or C++ code to an XOP?


Mostly you would have to wrap the existing code in calls that interface with Igor. The programmer would need to read various chapters in the XOP Toolkit manual to learn how to create an external function or external operation, how to receive parameters from Igor and return results, how to access wave data, and so on.

Quote:
What additional effort is needed to create a Mac-based XOP along with the Windows-based XOP?


If the XOP has no user interface or other OS dependencies then it is a matter of creating an Xcode project and recompiling in Xcode.

For further information including an link to the XOP manual, see http://www.wavemetrics.com/products/xoptoolkit/xoptoolkit.htm

December 31, 2014 at 11:48 am - Permalink

In addition to Howards comments,
1. THe payback has got to be good to write an XOP. For fitfuncs it can be worth it, especially if it's expensive to calculate and you are using something like Gencurvefit. The reason being is that it's much harder to debug/maintain/develop. If you're looking for a 5% gain don't bother, if it's 50% gain it may be worth it. My fitfunc sped up by a factor of ~10-30 when I went to C.
2. You can thread inside XOP's, but doing it in a cross platform manner can be hard (pthread). I think that designing the XOP for IGOR threading adds an extra level of difficulty.
3. If you have to link with other libraries then there are extra issues. It may be difficult to cross compile those.
4. You have to make a 32/64 bit windows version and a 32 bit OS X version (lots of potential OS combinations).
5. Interfacing to existing C++ code is not necessarily difficult, it all depends on how complicated the interface presented to IGOR will be.
6. The installation issues are more complicated for XOP's.

If you PM me with further details I could advise you further.

January 1, 2015 at 03:44 am - Permalink

Thank you Howard and Andy.

As a bit more background, my colleague has already developed a complete package (a Windows executable), however the graphics to it could be significantly improved. Based on what you both say, the better course at this point would simply be to export the data from the existing package to Igor Pro for graphing. Coding an application in an XOP may be something to try later down the line.

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

January 2, 2015 at 05:54 am - Permalink

Perhaps a relevant question here is whether the WM folks can make it easier for people to write XOPs (or, at least, XFUNCS). I'm not a C or C++ programmer myself, but I have asked students in my group at different times to write C/C++ code for both Igor and LabVIEW. The latter seems to be significantly easier for writing simple functions. LabVIEW can generate standard wrapper code so that all you need to do is insert the core C code. Passing variables, vectors, and matrices (in both directions) is straightforward. A recent student tried to do something similar to write a fit function and needed to learn probably way too much about how the interaction between Igor and C++ worked.

To put it another way, Student 1 did his task in LabVIEW in less than a week. Student 2 needed a couple of months. Both were beginning C++ and beginning-to-intermediate Igor programmers.

The XOP manual states (accurately) that "In order to write an XOP you need to be very familiar with Igor concepts such as waves, command line operations, procedures and experiments. Writing a simple XOP that just adds an operation or function to Igor requires advanced-beginner to intermediate programming skills. If you have less experience, you will need more patience."

A trend in programming environments is the ability to call up different languages, as needed. LabVIEW can call Matlab and Scilab. Mathematica can call R. Python can call C and Fortran. In Igor, it comes up fairly regularly that one wants to do something that is too slow in Igor, or there is existing C code for a given application that one might want to use.

The question is, Why can't all this be easier?


John Bechhoefer
Department of Physics
Simon Fraser University
Burnaby, BC, Canada

January 2, 2015 at 10:58 am - Permalink

bech wrote:
LabVIEW can generate standard wrapper code so that all you need to do is insert the core C code. Passing variables, vectors, and matrices (in both directions) is straightforward. A recent student tried to do something similar to write a fit function and needed to learn probably way too much about how the interaction between Igor and C++ worked.


To be fair, WM do provide lots of examples that one can springboard from. I started learning C when I wanted to write an XOP fit function, all I did was rename everything, change the innards slightly and it worked.

A.

January 2, 2015 at 11:54 pm - Permalink

John Bechhoefer's summary mirrors my thoughts and is supported by a follow-up conversation with my colleague. I would have hoped that methods to interface between Igor Pro and C/C++ (or Fortran or Python or ...) code would be ... less daunting. Even my colleague, who has extensive C/C++ coding experience, is not optimistic about the benefits of coding XOP functions to interface with the UI+graphics in Igor Pro as opposed to coding an entire stand-alone package (functions and UI) in C/C++ (and as needed, dumping the data as CSV for graphics in Igor Pro or ... surprise! ... simply in Excel). Granted, although I stand mostly as un-informed outsider on this, I'll leave as wishful thinking a feature request that a future version of Igor Pro can/will change that balance.

Thanks!

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

January 3, 2015 at 09:06 am - Permalink

My 2 cents on XOP coding as I do that on a regular basis:
- Use operations in your XOPs, boilerplate code can be generated with ParseOperationTemplate. They are so much easier to use than XOP functions.
- There is no igor-specific support for threads. I tend to use boost::thread in my projects. Remember to don't interact with igor from your internal threads.

I always found the example XOPs a good starting point on understanding on how to interface with Igor. Given bech's description on labview I beg to differ. Handling labview data structures inside C is far more complicated than handling igor waves inside C.

January 7, 2015 at 02:49 am - Permalink