[GRASS-dev] compilation error - macro _n()

[Glynn Clements]

Martin Landa wrote:

> recently I got problem compiling GRASS module against CGAL library.
> The source of problem is duplicated definition of _n() macro.
> 
> In file included from /usr/include/boost/random.hpp:37:0,
>                  from /usr/local/include/CGAL/spatial_sort.h:31,
>                  from /usr/local/include/CGAL/Triangulation_3.h:47,
>                  from local_proto.h:4,
>                  from main.cpp:25:
> /usr/include/boost/random/discard_block.hpp:60:42: error: macro "_n"
> requires 3 arguments, but only 1 given
>      discard_block_engine() : _rng(), _n(0) { }
> 
> GRASS defines _n() macro as [1], Boost is using _n() macro in different meaning.
> Any idea who to fix this problem correctly?

Boost isn't using any _n() macro; that's the C++ syntax for
initialising a member variable named _n upon construction.

At least, it isn't trying to use a macro. The fact that there happens
to be a macro called _n() in existence at that point is beyond its
control.

It's GRASS' fault for using a reserved name (_n() was added in r59156,
r59189, now 137 occurrences in 52 files), and particularly for using
it as a macro.

Including the CGAL headers before the GRASS headers would avoid this
specific issue.

Note that it's fairly common for C++ code to use such names within
class scope because C++ *has* class scope and "reserved" names aren't
reserved there. Names created in class scope don't affect other scopes
(and aren't affected by other scopes), and using a reserved name would
normally help to avoid this exact issue.

Macros aren't scoped, so the only way to avoid having a macro
definition breaking your code is to choose a name that's unlikely to
be used as a macro. Ordinarily, a name that's reserved to the
implementation in any scope (i.e. prohibited from being used as a
macro) would be a safe bet for that.

-- 
Glynn Clements <glynn at gclements.plus.com>