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: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2012-01-02 15:23:43

From: Edward Diener

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

> Any programmer who doesn't attempt to give distinctive names to macros 
> in their header file(s) is really clueless. I don't know who/what 
> "monotone" is but whoever did the programming for "it" has done a really 
> poor job by naming a macro "L".

We have seen this issue from Microsoft, Apple and Sun plus a host of smaller library vendors.  My favorite was the electrical engineering package that defined every symbol for electrical units as a macro that was the conversion factor to their standard units.  The world is literally full of clueless programmers, or rather, it is full of code written by clueless programmers that competent maintainers now feel unable to fix because it would break working code.  The standard library protects itself by prepending double underscore to every identifier that isn't a documented interface.  "#define T true" shouldn't break <vector> because it should be using __T and not bare T.  That is why boost breaks but not the stl when this silliness crops up (with the notable exception of min/max from windows.h since those are documented interfaces of the stl).  Since the syntax error is in boost files and not the offending macro (no way for compiler to point to the macro after preprocessor has garbled the code) people tend to complain to us because they don't understand the error.  The only way to protect oneself is to use long, descriptive variable names even for template parameters.  What normally happens is #undefine gets added to the user code or they swap the order of includes once they figure out why they are getting the error.

We could make a header file that defines every one, two or three character macro then undefines them.  Including that header would tell people where they have stupid macros defined because the preprocessor error would point them right to them.  I wouldn't want it included in any boost library though because it would break working code.  We all pay for the mistakes of the past, and we were all clueless programmers at some point.

Regards,
Luke