[MOAB-dev] portability issue/question

[Jason Kraftcheck]

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???

> 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.

> 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.

One extreme solution would be to remove the two offending functions from 
moab::Range.  Normally I wouldn't even mention this, but I don't 
particularly like these two functions.  The STL only provides 
index-based access for containers when the implementation it is O(1). 
It could potentially be O(n) for Range, leading people to accidentally 
write O(n^2) code.  These things could be done the same as one would for 
std::list (or for the index() method, almost any container): replace 
"range[i]" with "*(range.begin()+i)" and "range.index(h)" with 
"range.find(h)-range.begin()".  But the need for either should be rather 
obscure.  I'm having trouble imagining a case where it wouldn't be more 
efficient to work with iterators rather than indices.

- jason