Re: [boost] [function] function.hpp lacks include guard

Subject: Re: [boost] [function] function.hpp lacks include guard
From: Gennaro Prota (gennaro.prota_at_[hidden])
Date: 2008-10-22 18:16:43

Pete Bartlett wrote:
>>> Gennaro Prota wrote:
>>>>> #ifdef BOOST_FUNCTION_HPP_##BOOST_FUNCTION_MAX_ARGS
>>>>> #define BOOST_FUNCTION_HPP_##BOOST_FUNCTION_MAX_ARGS
>>>>> ...
>>>>> #endif
>>>> Clever... 
>>> Depressing...
> 
>> If only it compiled...
>>
>> In Christ,
>> Steven Watanabe
> 
> Doubtless I'm more easily impressed than Gennaro, but to me the general idea
> of doing only the arities you need to *is* quite clever
> 
> Sketch:
> 
> #ifndef BOOST_FUNCTION_MAX_ARGS_CURRENTLY_AVAILABLE_PLUS_1
> #define BOOST_FUNCTION_MAX_ARGS_CURRENTLY_AVAILABLE_PLUS_1 0
> #endif
> 
> #if (BOOST_FUNCTION_MAX_ARGS >
> BOOST_FUNCTION_MAX_ARGS_CURRENTLY_AVAILABLE_PLUS_1)
> 
> //do file iteration from 
> //BOOST_FUNCTION_MAX_ARGS_CURRENTLY_AVAILABLE_PLUS_1 to
> BOOST_FUNCTION_MAX_ARGS
> 
> #undef BOOST_FUNCTION_MAX_ARGS_CURRENTLY_AVAILABLE_PLUS_1
> #define BOOST_FUNCTION_MAX_ARGS_CURRENTLY_AVAILABLE_PLUS_1
> (1+BOOST_FUNCTION_MAX_ARGS) //ready for next include
> 
> #endif
> 
> I'm not sure how much gain you will see in practice as the inner headers
> will themselves already have include guards, but perhaps worth investigating
> nonetheless.

Seeing approval for the ## suggestion was twofold depressing:
because it doesn't work in C++ and, more importantly, because it
is a Boost leit motive: getting excited about solving problems
that nobody has. Most of Boost has become, alas, a big exercise
in mental masturbation and/or an attempt to show off one's
coding skills rather than solving problems.

The competent programmer isn't impressed by all this. In fact,
he avoids it like the plague (google for <Dijkstra competent
programmer skull>).

PS: I won't reply further. I know these are hard-to-break habits
and that many are convinced that there's a point in them. In
fact, much of this school of thought --though not this specific
"#if improvement" case -- can go under the label of "premature
generalization": as much as you can spot an inexpert, naive
programmer from his premature optimization concerns you can spot
one from premature generalization.

-- 
Genny