April 2015
22
T
OOLS
& S
OFTWARE
V4.0 High Integrity C++ coding
standard - one year on
By Richard Corden,
PRQA
In this article the author provides a
brief review of the past 12 months
with HIC++ V4.0, identifying the rules
which have been most frequently
referenced, looking at some of the
feedback from the user community,
and touching on some of the ongoing
discussions between the experts on
the best way to use the new language
that is Modern C++.
On 3 October 2003, PRQA published the
initial version of the High Integrity C++ cod-
ing standard (HIC++). Over the subsequent
decade the developer community has down-
loaded this coding standard a staggering
25,000 times. Exactly 10 years a er the initial
publication, on 3 October 2013, we released a
major revision of HIC++. e updated V4.0
rule set builds on the lessons of the previous
10 years, incorporating feedback from the
HIC++ user community, learning from other
standards, and most importantly addressing
recent changes made to the C++ language
itself (in particular C++ 2011).
Many, including Bjarne Stroustrup himself,
see Modern C++ as a whole new language
.
html#think). ISO C++ 2011 added many new
features, and a key objective of many of the
changes has been to make the language eas-
ier to use and to enable developers to explic-
itly express their intent rather than through
learned idioms. As a result, modern C++ is
(or should be) a safer language than its pre-
decessor. e need to better understand and
to promote the best/correct use of the new
features was one of the main drivers behind
the creation of HIC++ V4.0. We are also more
aware of the importance of well constructed
rules, in particular, that rules need to be
enforceable, unambiguous and have a clear
rationale. Rationale is extremely important as
this enables informed decisions to be made
about conforming to or deviating from a rule
within a given context. A rule that is vague
or not enforceable - either through manual
inspection or automatic analysis - is useless
and a waste of the engineer’s valuable time.
Wherever possible, rules should be automat-
ically enforceable, freeing up time to focus on
the higher level design and structural issues.
And, of course, we feel compelled to point out
that all automated static analysis tools are not
equal (!), speci cally in terms of their accu-
racy - minimizing false positives (noise) and
false negatives (a failure to identify genuine
issues).
e V4.0 rule set has been derived from mul-
tiple sources: rules adopted from V3.3, the
prior version of HIC++ and improved (retired,
merged, reworded, relaxed or extended), rules
adapted from other existing standards, advice
from the experts (such as Herb Sutter, Scott
Meyers, Anthony Williams), direct analysis
of the ISO C++ 2011 standard by PRQA lan-
guage experts, and monitoring of language
changes for C++ 2014 and beyond through
direct participation of the C++ Committee
meetings. Overall the transition from V3.3
to V4.0 is summarized as an excerpt from
PRQA whitepaper: High Integrity C++ Cod-
ing Standard V4.0 - an overview and shown
in gure 1. HIC++ continues to di er from
the other mainstream coding standards such
as MISRA C++ and JSF++. Unlike JSF++ no
major feature is prohibited, instead the best
available advice is provided for the correct use
of all language features. Furthermore HIC++
addresses issues using the C++ approach of a
single powerful rule that removes the need for
many disjoint rules. Rule 12.5.6 (see below) is
a good example of this as it avoids the need for
rules relating to checking for self-assignment
or providing the strong exception guarantee.
e adoption of HIC++ is truly global, with
developers from 137 countries having visited
the HIC++ website
.
com) since the publication of V4.0. Most
interest has come from US and Germany
(each accounting for 20% of visits) followed
by: Russia, UK, India, Sweden, France, Poland
then Switzerland, and the remaining 127 (I
won’t list them all!). One of the most inter-
esting and informative exercises has been
to identify the rules which the development
community has most frequently referred
to, and below nd the Top 5 Rules based on
combination of web page hits and direct feed-
back on the downloaded PDF version (table
1). Let me consider each of these in a little
more detail. To date Rule 8.2.4 has been con-
sulted more o en than any other rule in V4.0.
No doubt this is as a direct consequence of a
Figure 1. Summarized transition
fromHIC++ V3.3 to HIC++ V4.0
