The Mastermind of C++, or… Part 4 Debugging

Ianjoyner
2 min readJul 23, 2024

--

This is the fourth of a series of articles examining a 2009 interview with Bjarne Stroustrup. The first part is here with links to the other parts:

Part 1

Part 3

Debugging

Stroustrup is asked about debugging. C/C++ are brute-force languages, and testing and debugging will also be by brute force. Modern languages try to catch errors as early as possible by static checking. Not only did C have little static checking (some confuse simple syntax checking with more general checking), but it has many flaws and traps for programmers to fall into and must always be conscious of. These are a serious source of bugs, and often ones that are difficult to spot. C++ tried to fix some of this deficiency, but in the most part just magnified the problems.

Design by Contract (DbC) is a fundamental technique, based on Hoare Logic, that is both static and dynamic checking. Design by Contract is implicit in static checking like type checking. But with Design by Contract, programmers can express more checkable logic about the program, including dynamic checks at run time. C can claim it has such things in asserts, but these a primitive brute-force ways of doing DbC, and not particularly integrated with the language, rather added as afterthoughts.

The original language to do DbC (back in the 1980s) had DbC at the core. This was even more central than OO classes and inheritance. The committee doing C++26 are thinking about DbC, but it will be another afterthought bolted on the side, rather than real support from the core of the language. Programmers may optionally use it like classes in C++, but often opt not to as too much bother. It will be lipstick on a pig.

Part 5

--

--