[MOAB-dev] portability issue/question

Paul Wilson wilsonp at engr.wisc.edu
Mon Aug 2 10:24:45 CDT 2010


Jason Kraftcheck wrote:
> On 07/29/2010 07:00 AM, Paul Wilson wrote:
>> Hello,
>>
>> I am integrating MOAB/DAGMC into a c++ code that includes a header that
>> defines index() as a macro, apparently through some combination of
>> system headers.
>
> That's really ugly.  It comes from a system header???
I tracked it down to an X11 header: X11/Xos.h.  It appears to want to 
provide index() and rindex() as aliases for strchr() and strrchr().  The 
comments suggest that some systems already provide these and it only 
defines them if they are not already defined.  However, string.h does 
define these, just not as macros.
>
>> This creates a problem with including moab/Range.hpp
>> because it attempts to define a member function index().
>
> It also has an argument named 'index' in one spot.
This is not a problem since the macro is a function macro (?) and 
requires 2 arguments.  It complains about the existence of index() with 
a single argument.
>
>> Fortunately it
>> creates a compile time failure because the signature of the
>> Range::index() is different from the macro, otherwise who knows what
>> would happen???
>>
>> I haven't bothered to track it down yet, but the short solution has been
>> to add the following immediately prior to the include:
>>
>> #ifdef index
>> #undef index
>> #endif
>>
>> I have resisted committing this to the repo because it seems like a
>> little presumptious/overbearing. Any other solutions?
>>
>
> In general, I can't think of a better way to work around really poor 
> macro name choices like this.  Undef whatever you need to right after 
> including the offending header.  Or if you need to include the 
> offending header in more than one place, write a wrapper header that 
> includes it and any necessary #undefs.
>
> The ideal solution would be to fix the offending header, but I assume 
> that isn't an option.
I think the X11 header needs to be fixed but that us outside our scope.  
On a different note, I can make this go away by changing the order that 
things are included, in this case.

Paul

-- 
Paul Wilson

-- ------------------------------------------------------------------ --
Paul P.H. Wilson              419 Engineering Research Building
wilsonp at engr.wisc.edu                       1500 Engineering Dr
ph/fax: 608/263-0807                          Madison, WI 53706

           My calendar: http://bit.ly/pphw-calendar

       Computational Nuclear Engineering Research Group
               http://cnerg.engr.wisc.edu

          Associate Professor, Nuclear Engineering
              Engineering Physics Department     
               http://www.engr.wisc.edu/ep       

        Chair, Energy Analysis & Policy Certificate
         Nelson Institute for Environmental Studies
                http://nelson.wisc.edu/eap/

          Contributing to the joy and improvement
                  of all those around me

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3297 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20100802/7daf1a6e/attachment.bin>


More information about the moab-dev mailing list