April 2015
23
T
OOLS
& S
OFTWARE
recent debate between Scott Meyers and Herb Stutter. ese two heavy
hitters of C++ have been have been discussing the topic covered by
Rule 8.2.4 Do not pass std::unique_ptr by const reference. e argu-
ments on both sides are compelling, and it seems both approaches have
advantages and disadvantages. Ultimately HIC++ follows the advice of
Herb Sutter, that sink parameters of type “std::unique_ptr” should be
passed by value. Scott Meyers, on the other hand, argues for a more
general rule to declare sink parameters as rvalue references (&&).
void herb_sp (std::unique_ptr<int>);
void scott_sp (std::unique_ptr<int> &&);
It is great to see that the community is also consulting HIC++ to
canvass our opinion on this topic!
e next most popular rule visited on the website is “Rule 4.1.1 Ensure
that a function argument does not undergo an array-to-pointer conver-
sion”, whose origin comes from the JSF C++ standard. e issue arises
because a function parameter that looks like an array is actually just a
pointer:
void f1(int a[10]) { // Equivalent to void f1(int*)
a[8] = 0; // Out of Bounds when called from f2
}
void f2() {
int b[5];
f1(b); // Not illegal code!
}
A human reviewer can easily be swayed by the array dimension in f1
believing that this is checked by the compiler, however no checking
will take place. In JSF C++, the passing of array arguments is disal-
lowed completely for this reason. HIC++ V4.0 however, allows arrays
to be passed as arguments, but only when the dimension information
is not lost:
void f1(int (&a)[10]) { // Parameter is reference to
// array of 10 elements.
a[8] = 0; // Guaranteed to be legal
}
void f2() {
int b[5];
f1(b); // Illegal – Compile Error
// Cannot convert int[5] to int[10]
}
I must thank the HIC++ user community for all their feedback, almost
all of which has been constructive and positive. Technical feedback has
typically related to suggestions for relaxations of rules or the addition
of clari cations. For example, Rule 2.1.1, Do not use tab characters in
source les as currently worded, requires that spaces be used exclu-
sively in source les. e rationale for disallowing tabs is to ensure that
code indentation is consistent between di erent editors and IDEs, for
example:
if ( ... ) {
++i; // 4 spaces
++j // 1 tab - indentation incorrect
// when tab not equal to 4 characters
}
We received feedback (thanks to Jason, Larry and
Dave) that this is may be too restrictive. e issue is
also addressed when tabs are always used to start the
line:
if ( ... ) { // 1 tab before if
++i; // 2 tabs before ++i
++j // 2 tabs before ++i
} // 1 tab before {
Our intention is to re ect minor improvements such as this in subse-
quent revisions of the standard.
Developer communities are clearly a rich source of information on the
best way to use Modern C++. O en, much can be learned from the ques-
tions and answers that appear on such forums. One example relates to
Rule 12.5.6 Use an atomic, non-throwing swap operation to implement
the copy and move assignment operators, which is covered by many
questions and answers on forums such as StackOver ow. is rule helps
ensure the correct copying and moving of a class while providing for
strong exception safety. is is excellent advice, as well as providing a
simple and consistent way to layout these members in a class. What has
come to light, however, is that the V4.0 rule example can be written as:
class A {
public:
A (A const &) …
A (A &&) …
A & operator=(A rhs) & noexcept {
swap (*this, rhs);
return *this;
}
};
is is a great example of where the correct approach ends up being far
better and simpler than the alternatives!
In the Urbana-Champaign ISO C++ Committee Meeting (3 to 8
November 2014), a formal vote took place to remove trigraphs from
the language (n3981). Trigraphs are a sequence of 3 characters begin-
ning with ??. eir purpose is to allow C and C++ to be written on
systems that don’t support characters such as {, /, # etc. Unfortunately,
trigraphs don’t behave well with some of new language features such as
raw string literals.
const char * s = R”??=”;
A prior survey found that trigraphs were either being used unintention-
ally or explicitly as part of testing trigraphs! e verdict is therefore to
remove them completely from the language. It turns out that Rule 2.2.1
Do not use digraphs or trigraphs was an extremely valuable rule to fol-
low. e only remaining question is will the same happen for digraphs?
One year on and the adoption of HIC++ V4.0 has surpassed our expec-
tations, having been downloaded an additional 3,800 times over the
past 12 months. is demonstrates the continued relevance of HIC++,
and re ects the fact that HIC++ continues to evolve and to accom-
modate Modern C++, helping to document best practices and help-
ing developers to generate High Integrity C++ Code. HIC++ V4.0 is
available at
, together with an accompanying
whitepaper. If you have any additional feedback please do not hesitate
to contact me at
.
Table 1. Results based on combination of web page hits and direct feedback to de ne the
Top 5 Rules
