Re: [boost] Boost Library Guidelines

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-04-25 11:32:57

>From: "Paul A. Bristow" <boost_at_[hidden]>

> I have been reading the Boost Library Requirements & Guidelines. (Gasps of
> amazement?).
>
> May I suggest that we add to
>
> Aim for ISO Standard C++ ...
>
> "Try to code so that  compiles with 'strict' compiler settings and try to
code
> avoiding 'extensions' as far as possible."
>
> Although the defaults for MSVC 7.0, for example, is for warnings at level
3 and
> allowing 'extensions', I believe it will reduce Fear Uncertainty and Doubt
in
> future if we try to use level 4 and no extensions.
>
> I suspect that with a marginal extra effort on the part of authors, many
Boost
> library items could be free of warnings, even at level 4. In a number of
cases I
> have noted, a few static_casts would suffice.
>
> Of course, this is not always possible.  In some cases a comment that some
> warnings can be safely ignored would be reassuring.

I use the highest warning level (4) for MSVC and Intel C++, and strict mode
for the latter, to not ignore any warnings/remarks by default. In the
cpp-files, not headers, I then selectively disable remarks/warnings that are
harmless (and there's a lot of them), until it compiles without
remarks/warnings. I think one should not get used to ignore warnings in the
output, or one could easily miss some which _does_ matter, which is why I
disable the ones that don't.

In many cases, on level 4, there's _no_ practical way to turn off a
remark/warning, without using #pragma. Therefore, I think it may be better
to use a #pragma (in the cpp-file), than telling the user to ignore the
remarks/warnings. In header-only libraries, like much of the Boost
libraries, this leaves it up to the user, anyway.

For examples of level 4 remarks/warnings on Intel C++, consider these:

void f(int a,int b) {} // remark #1418: external definition with no prior
declaration

struct derived : base {}; // remark #304: access control not specified
("public" by default)

f(g(),h()); // remark #981: operands are evaluated in unspecified order

Regards,

Terje