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: Marshall Clow (mclow.lists_at_[hidden])
Date: 2012-01-01 19:51:38

On Jan 1, 2012, at 4:30 PM, Steve M. Robbins wrote:

> Hello,
> 
> Boost Developers: I recently did rebuilds of all Debian packages that use Boost
> with Boost 1.48 and this is one of the casualties of the upgrade (from 1.46.1).
> 
> 
> On Sat, Dec 31, 2011 at 12:02:37PM +0100, Zack Weinberg wrote:
>> On Fri, Dec 30, 2011 at 9:53 PM, Steve M. Robbins <smr_at_[hidden]> wrote:
>>> This package failed to build using the newest Boost version 1.48:
>> ...
>>> /usr/include/boost/math/special_functions/detail/lgamma_small.hpp: In function 'T boost::math::detail::lgamma_small_imp(T, T, T, const mpl_::int_<0>&, const Policy&, const L&)':
>> ...
>>> /usr/include/boost/math/special_functions/detail/lgamma_small.hpp:483:38: error: expected primary-expression before 'do'
>> 
>> I'm not in a position to verify this for myself for another week, but
>> I have a horrible feeling I know what's wrong:  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.
> 
> Zack, you are absolutely right.  The lgamma_small header has a templated
> class method using "L" as one of the templates:
> 
> template <class T, class Policy, class L>
> T lgamma_small_imp(T z, T zm1, T zm2, const mpl::int_<0>&, const Policy& pol, const L&)
> 
> The compile error at line 483 is at a call to L():
> 
>      result = log(gamma_imp(z, pol, L()));
> 
> 
>> I'd argue that Boost headers should take care to defend themselves
>> from the possibility of such macros, but fixing that in Boost might be
>> an enormous amount of work, and in any case, 1.48 is already out
>> there.

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' ;-)

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists_at_[hidden]>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki