Boost logo

Boost :

Subject: [boost] [fusion] What do we do with nil ?
From: Joel de Guzman (joel_at_[hidden])
Date: 2012-11-29 19:11:38


This is a constantly nagging issue. There are a couple of places where
nil is a PP define especially on the Mac:

   - objc.h

   #ifndef nil
   #define nil __DARWIN_NULL


   - MacTypes.h

   #ifndef nil
   #define nil NULL

So people complain because fusion uses nil as:

    namespace boost { namespace fusion { struct nil; }}

So, nil is a reserved word in Objective-C. But this is C++!
And that define is SUCH A BAD PRACTICE in C++! Some folks,
like Paul Mensonides maintains a strong stance against this:

   I would just use

   #define nil nil

   as a sanity check and call it done. If the symbol is already defined,
   compilation error (or at least warning on overly permissive compilers).
   The symbol will be need to be undefined in between the inclusion of the
   two libraries.

   Workarounds like nil_ and (min)(...) just perpetuate the problem. Fix the
   root problem rather than treating the symptom indefinitely. Otherwise,
   where is the line drawn? Even if you can't provide a transparent fix
   (such as defining nil as a constant and min/max as functions), the
   backwards compatibility argument fails in the long run. The amount of
   effort required to make the necessary changes to existing code will
   eventually be outweighed by the effort to implement workarounds put into
   new code (as well as educate everyone that they are necessary)--especially
   in cases like these which can mostly be emulated in a way that causes most
   existing code to work.

As I said over and over again, I'm listening and I would want to "fix"
this issue if someone comes up with a reasonable (tested) patch that:

1) Detects the platform
2) Renames fusion::nil to something else (only for the affected platform)

Yet, no-one wants to do this. Instead we get nasty remarks such as those
found here:

What do we do? I'm seeking for a resolution.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at