• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE section PUBLIC "-//Boost//DTD BoostBook XML V1.1//EN"
3"http://www.boost.org/tools/boostbook/dtd/boostbook.dtd">
4<section id="safe_numerics.promotion_policies.cpp">
5  <title>cpp&lt;int C, int S, int I, int L, int LL&gt;</title>
6
7  <section>
8    <title>Description</title>
9
10    <para>This policy is used to promote safe types in arithmetic expressions
11    according to the rules in the C++ standard. But rather than using the
12    native C++ standard types supported by the compiler, it uses types whose
13    length in number of bits is specified by the template parameters.</para>
14
15    <para>This policy is useful for running test programs which use C++
16    portable integer types but which are destined to run on an architecture
17    which is different than the one on which the test program is being built
18    and run. This can happen when developing code for embedded systems.
19    Algorithms developed or borrowed from one architecture but destined for
20    another can be tested on the desktop.</para>
21
22    <para>Note that this policy is only applicable to safe types whose base
23    type is a type fulfilling the type requirements of <link
24    linkend="safe_numerics.integer">Integer</link>.</para>
25  </section>
26
27  <section>
28    <title>Template Parameters</title>
29
30    <informaltable>
31      <tgroup cols="3">
32        <colspec align="left" colwidth="1*"/>
33
34        <colspec align="left" colwidth="1*"/>
35
36        <colspec align="left" colwidth="6*"/>
37
38        <thead>
39          <row>
40            <entry align="left">Parameter</entry>
41
42            <entry align="left">Type</entry>
43
44            <entry>Description</entry>
45          </row>
46        </thead>
47
48        <tbody>
49          <row>
50            <entry><code>C</code></entry>
51
52            <entry>int</entry>
53
54            <entry>Number of bits in a char</entry>
55          </row>
56
57          <row>
58            <entry><code>S</code></entry>
59
60            <entry>int</entry>
61
62            <entry>Number of bits in a short</entry>
63          </row>
64
65          <row>
66            <entry><code>I</code></entry>
67
68            <entry>int</entry>
69
70            <entry>Number of bits in an integer</entry>
71          </row>
72
73          <row>
74            <entry><code>L</code></entry>
75
76            <entry>int</entry>
77
78            <entry>Number of bits in a long</entry>
79          </row>
80
81          <row>
82            <entry><code>LL</code></entry>
83
84            <entry>int</entry>
85
86            <entry>Number of bits in a long long</entry>
87          </row>
88        </tbody>
89      </tgroup>
90    </informaltable>
91  </section>
92
93  <section>
94    <title>Model of</title>
95
96    <para><link
97    linkend="safe_numerics.promotion_policy">PromotionPolicy</link></para>
98  </section>
99
100  <section>
101    <title>Example of Use</title>
102
103    <para>Consider the following problem. One is developing software which
104    uses a very small microprocessor and a very limited C compiler. The chip
105    is so small, you can't print anything from the code, log, debug or
106    anything else. One debugs this code by using the "burn" and "crash" method
107    - you burn the chip (download the code), run the code, observe the
108    results, make changes and try again. This is a crude method which is
109    usually the one used. But it can be quite time consuming.</para>
110
111    <para>Consider an alternative. Build and compile your code in testable
112    modules. For each module write a test which exercises all the code and
113    makes it work. Finally download your code into the chip and - voilà -
114    working product. This sounds great, but there's one problem. Our target
115    processor - in this case a PIC162550 from Microchip Technology is only an
116    8 bit CPU. The compiler we use defines INT as 8 bits. This (and a few
117    other problems), make our algorithm testing environment differ from our
118    target environment. We can address this by defining INT as a safe integer
119    with a range of 8 bits. By using a custom promotion policy, we can force
120    the evaluation of C++ expressions in the test environment to be the same
121    as that in the target environment. Also in our target environment, we can
122    trap any overflows or other errors. So we can write and test our code on
123    our desktop system and download the code to the target knowing that it
124    just has to work. This is a huge time saver and confidence builder. For an
125    extended example on how this is done, look at <link
126    linkend="safe_numerics.safety_critical_embedded_controller">Safety
127    Critical Embedded Controller</link> .</para>
128  </section>
129
130  <section>
131    <title>Header</title>
132
133    <para><code><ulink
134    url="../../include/boost/safe_numerics/cpp.hpp"><code>#include
135    &lt;boost/numeric/safe_numerics/cpp.hpp&gt; </code></ulink></code></para>
136  </section>
137</section>
138