Channels ▼


Ada-style Ranged Types in C++


In order to determine what kind of saving could be achieved, I defined a test using the expression:

The values of the constants a, b, c, d and the variables w, x, y, z were all chosen so that the expression would never overflow. Three cases were done. The first used unsigned int. The second used a range type defined similar to one above. The third was like the second, except the code was compiled so that the checks were always done regardless of the possibility of overflow. For each case, the expression was put in an external function which was executed several million times, and an average elapsed time for one execution calculated. For this particular test, using my machine, and my compiler (Visual C++ Toolkit 2003 (13.10.3077), optimization level O2) the results were:

1st case: 0.0246 seconds
2nd case: 0.0297 seconds
3rd case: 0.1119 seconds

The results using GCC (MinGW 3.4.2, optimization level O3) were similar. This was an admittedly contrived test, but I was interested in seeing what the best case savings would be. Your mileage may vary.

There are various ways to reduce the cost of the overflow checking at the cost of portability. One way is to increase the assumptions made by the code. For example, if your implementation treats signed overflow in a benign and predicable way, then you can simplify those checks. Even more time can be saved by using inline assembly, if your compiler has such a feature.


The ranged_type class template provides integral types that are safe from overflowing and constrained to a given range. Using templates allows much of the overhead of the checks to be removed, though it is not possible to remove all. There is always some cost associated with safety. In the future, I'd like to expand the implementation to include floating point types, but only time will tell if that is even possible.

This class is part of a free C++ library of classes I have written over the years and have found useful in my own programs. The latest version can always be found here:

I would like to thank my peer reviewer, Victor Bazarov, for his invaluable help and insight.

Rich has thirteen years experience as a software engineer. For the past eight years he has been employed by Lockheed Martin Systems Integration in Owego, NY writing real-time embedded systems oriented towards avionics. He can be contacted at

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

