[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