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