Subject: Re: [boost] [Boost.Math] Re: [Monotone-debian] Bug#653764: FTBFS with Boost 1.48: lgamma_small.hpp:483:38: error: expected primary-expression before 'do'
From: Joshua Juran (jjuran_at_[hidden])
Date: 2012-01-02 06:04:36
On Jan 1, 2012, at 4:51 PM, Marshall Clow wrote:
> On Jan 1, 2012, at 4:30 PM, Steve M. Robbins wrote:
>> On Sat, Dec 31, 2011 at 12:02:37PM +0100, Zack Weinberg wrote:
>>> Monotone defines
>>> several one-character macros for its own use, and L() is one of
>>> It looks like Boost is using L() for its own purposes and
>>> expecting it
>>> not to be a macro.
>>> I'd argue that Boost headers should take care to defend themselves
> How, though?
> #undef L
> That would break client code.
>> Boost.Math developers: What is the right thing to do here? More
>> descriptive class template parameters?
> This is a hard problem - because pretty much whatever identifier
> gets chosen, you have a chance that some program/library/package
> somewhere has defined it in a macro.
> Several years ago, I worked with a guy who was passionately anti-C++.
> He said, "Look - it's all crap. if I add '#include <vector>' to my
> source file, all of a sudden I get all these compile errors! What
> kind of idiot writes this stuff?"
> Finally, I got tired of his complaining, and looked at the problems
> that he was having.
> Buried in one of his header files was '#define T true' ;-)
The error is defining macros under likely-to-collide names which will
be seen by code outside of your control. Monotone should either use
a more descriptive name or define the macro after including foreign
headers. Mr. T's problem has too many solutions to list, but since
he likes C, I'll just say s/T/1/g.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk