Is there anyone on this list responsible for Boost.Fusion, or interested in it working on Mac OS X? The silence is somewhat disconcerting.. Best, Rich On Sun, May 19, 2013 at 8:07 PM, Rich E wrote:

I just attached this patch to the 2 year old ticket here:

https://svn.boost.org/trac/boost/ticket/5010#comment:20

Is it possible that this could be reviewed and included in 1.54? Our users constantly run into obscure compiler issues related to this nil symbol conflict, furthermore we would like to use Boost.Log in 1.54 but won't be able to without this simple change.

Thanks for your time, Rich

On Mon, Apr 29, 2013 at 1:54 PM, Rich E wrote:

...

I see there was work about 5 months ago to avoid the Obj-C++ nameclash with nil in Boost.Fusion:

https://github.com/boostorg/fusion/commit/12d2898287a124ff4b398fd3fff512b6f9...

Thanks for that as there are alot of use using boost in this scenario. However, I have found another couple nameclashes that prevented me from linking against Boost.Log in the latest trunk on OS X with clang, when trying this sample code:

http://boost-sandbox.sourceforge.net/libs/log/example/doc/tutorial_trivial_f...

Attached is the changeset I needed to make to build. Does this seem acceptable to the maintainers?

Best, Rich

On Wed, May 22, 2013 at 7:23 PM, Michael Caisse wrote:

I believe your patch will get merged. I'm sure you can appreciate the lack of enthusiasm to fix bad vendor choices... like indiscriminate use of macros (o;

Thanks, I do understand the frustration when having to deal with these petty issues that are rooted in flaws of a core language. But while I don't agree with many choices apple made in their usage of the global namespace in obj-c, many of us have to live with it and still hope to take advantage of the good work done in boost as well as Cocoa. In the end, after many decisions have already been made, we would just like all these tools to work in harmony. cheers, Rich