Boost logo

Boost :

From: Luke Stebbing (ls_at_[hidden])
Date: 2003-11-17 19:41:39

Beman Dawes wrote:
> When it is required that code compile without triggering warning X, in
> effect the C++ language has been changed to no longer allow whatever is
> triggering X.
> That's OK, if X is virtually always a programming problem. But if it is
> sometimes perfectly good code, then I wouldn't want to see that warning
> enabled.

It seems to me that both the library users and the library implementors have
various requirements and preferences, and the two should be insulated from
one another as much as possible. Here, making -Wshadow usable for clients
who want it would force Boost developers to avoid shadowing code (or spend
the energy to work around it with #pragmas). As you pointed out, this could
restrict perfectly good code and force workarounds throughout Boost,
depending on the warning in question. However,

> No. Only enable warnings for conditions which are actually errors the
> overwhelming majority of the time.

the correctness of that statement depends on context. Warnings that fail to
meet that criterion in Boost code may still be beneficial in client code.

The warnings used by library clients should be independent of the warnings
used by library developers, and failing that, substantial client preferences
should supersede the preferences of the service provider. The difficulty
lies in estimating how many clients would find a given warning useful, how
useful they would find it, and the cost of providing the service. I'm not
intimately familiar with the Boost (header file) codebase, so I can't answer
that last question, but I do know that detecting shadowing has come in handy
for me.

- Luke Stebbing

Boost list run by bdawes at, gregod at, cpdaniel at, john at