Conflict between Igor libraries and Measurement Computing for XOPs

Share icon

Wed, 07/31/2013 - 09:24 am

There seems to be a conflict between the IGOR "C" headers and the measurement computing headers. In two instances they define using the same names, BADRANGE and IDLE. I'm guessing that these are fairly common and that this has come up before.

What is the best solution, given I have no access to the source code for either?

--------------------------------------------------------------
Summary of errors from compile logs
--------------------------------------------------------------
1>c:\users\public\documents\measurement computing\daq\c\cbw.h(55): warning C4005: 'BADRANGE' : macro redefinition
1> c:\program files (x86)\wavemetrics\xop toolkit 6\igorxops6\xopsupport\igorerrors.h(62) : see previous definition of 'BADRANGE' (TaskId:17)
1>c:\users\public\documents\measurement computing\daq\c\cbw.h(360): warning C4005: 'IDLE' : macro redefinition
1> c:\program files (x86)\wavemetrics\xop toolkit 6\igorxops6\xopsupport\xop.h(224) : see previous definition of 'IDLE' (TaskId:17)

Expansion: header code comparisons
1) #define BADRANGE
Measurement Computing cbw.h
* C/C++ Windows header for Measurement Computing Universal Library
/* System error code */
#define BADRANGE 30 /* Invalid range specified */

IGOR igorerrors.h
// From IgorErrors.h.
#define BADRANGE 18 // insufficient range

2) #define IDLE
Measurement Computing cbw.h
* C/C++ Windows header for Measurement Computing Universal Library
/* Status values */
#define IDLE 0

IGOR xop.h
// *** XOP Message Codes -- Codes passed from Igor to XOP ***
// Basic messages
#define IDLE 2 //

--------------------------------------------------------------
compile logs attached from visual studio express 2012
-------------------------------------------------------------- 20120731 1143build1_0.txt 20120731 1151build4_0.txt
Hi,

I would split the code into two source files, one wich handles the interfacing with measurement computing and the other one which interfaces with Igor.
And you then call functions from the other.
As in that case only the source files include the headers, there will be no symbol clash.

So it will look like

comp.cpp
<br />
#include <cbw.h><br />
<br />
void DoStuff(...)<br />
{<br />
<br />
}<br />


comp.h
<br />
void DoStuff(...)<br />


handleIgor.cpp
<br />
#include <xop.h><br />
#include <comp.h><br />
// no clash as comp.h does *not* and must not include cbw.h<br />
<br />
// use DoStuff(...)<br />

July 31, 2013 at 09:49 am - Permalink

Quote:
There seems to be a conflict between the IGOR "C" headers and the measurement computing headers. In two instances they define using the same names, BADRANGE and IDLE. I'm guessing that these are fairly common and that this has come up before.


Don't #include XOP headers and MCC headers in the same file. Keep your MCC routines in one or more separate files that define routines you call from XOP code. #include the MCC headers from the MCC interface files only.

Alternatively you can do this:
#include "XOPStandardHeaders.h" #undef IDLE // IDLE is also #defined by MCC #undef BADRANGE // BADRANGE is also #defined by MCC #include "MCC.h"

July 31, 2013 at 11:13 am - Permalink

If I split it, then the duplicates get individual names that prevent the problem, yes? The linker will see the BADRANGE and IDLE #defines as separate entities thus avoiding conflict. If that works, GREAT!

I'll try it.
Thanks.

July 31, 2013 at 12:17 pm - Permalink

Quote:
If I split it, then the duplicates get individual names that prevent the problem, yes? The linker will see the BADRANGE and IDLE #defines as separate entities thus avoiding conflict. If that works, GREAT!


It's not that they get individual names. It's that, for any given compilation unit (.cpp file) these macros are defined only once. They have one definition in XOP source files and other definition in MCC source files.

Macros (created by #define) exist only from the time the compiler sees the #include directive in a given file until the end of the compilation for that file.

July 31, 2013 at 02:07 pm - Permalink