Quoting Niels Dekker - mail address until 2008-12-31 <nd_mail_address_valid_until_2008-12-31@xs4all.nl>:

Okko Willeboordse wrote:

...

My co-worker Bob Praster found, using PC-Lint 9.0, that function.hpp doesn't have an include guard like;

Mathias Gaunard wrote:

...

That's most likely because it doesn't need one, since it's only including other headers.

If so, it's probably just a matter of taste. Personally I always add those include guards to my headers, even when they're not strictly needed. Once in a while I might have to look into the preprocessor output, because of some buggy macro call of mine. In that case, I appreciate having each header included only once, to reduce the amount of noise in the preprocessor output file.

...

#ifndef BOOST_FUNCTION_HPP #define BOOST_FUNCTION_HPP ... #endif // BOOST_FUNCTION_HPP

Is it allowed to have an #endif followed by comment, on the very same line?

Kind regards, -- Niels Dekker

I haven't tested it, but looking at the code I think you can include boost/function.hpp multiple times and if BOOST_FUNCTION_MAX_ARGS is (re-)defined between any of those inclusions then everything still works as you'd hope. Pete

On Tue, Oct 21, 2008 at 6:09 PM, Doug Gregor <doug.gregor@gmail.com> wrote:

On Tue, Oct 21, 2008 at 9:41 AM, Peter Bartlett <pete@pcbartlett.com> wrote:

...

I haven't tested it, but looking at the code I think you can include boost/function.hpp multiple times and if BOOST_FUNCTION_MAX_ARGS is (re-)defined between any of those inclusions then everything still works as you'd hope.

Yep, that's why it doesn't have include guards.

Didn't this already come up? Maybe put a comment in the source file to try to avoid having to answer the same question again? --Beman

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Tcherepanov

Since this variable is not gets redefined very often in the user projects,

may be it is possible to introduce include guard that depends on this variable as well?

#ifdef BOOST_FUNCTION_HPP_##BOOST_FUNCTION_MAX_ARGS #define BOOST_FUNCTION_HPP_##BOOST_FUNCTION_MAX_ARGS ... #endif

Clever... Without changes to the code though, in situations where you know the arity, N, of the boost::function template to be instantiated, you can just include <boost/function/functionN.hpp> for a similar speed up. Pete

AMDG 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

AMDG Pete Bartlett wrote:

#if (BOOST_FUNCTION_MAX_ARGS > BOOST_FUNCTION_MAX_ARGS_CURRENTLY_AVAILABLE_PLUS_1)

<snip>

#define BOOST_FUNCTION_MAX_ARGS_CURRENTLY_AVAILABLE_PLUS_1 (1+BOOST_FUNCTION_MAX_ARGS) //ready for next include

Unfortunately, macros used in another macro definition are not substituted immediately, so this is equivalent to #if (BOOST_FUNCTION_MAX_ARGS > (1+BOOST_FUNCTION_MAX_ARGS)) In Christ, Steven Watanabe

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

on Wed Oct 22 2008, Gennaro Prota <gennaro.prota-AT-yahoo.com> wrote:

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.

You seriously think so? That's discouraging to hear. It makes me wonder why you'd waste your time reading and posting to this list. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

Niels Dekker - mail address until 2008-12-31 wrote:

Is it allowed to have an #endif followed by comment, on the very same line? Yes. It's been discouraged in the past, because of old preprocessors not handling C++ comments. But for Boost, old preprocessors are probably a minor concern.

Sebastian