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'

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

Josh