138 lines
4.7 KiB
XML
138 lines
4.7 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE section PUBLIC "-//Boost//DTD BoostBook XML V1.1//EN"
|
|
"http://www.boost.org/tools/boostbook/dtd/boostbook.dtd">
|
|
<section id="safe_numerics.promotion_policies.cpp">
|
|
<title>cpp<int C, int S, int I, int L, int LL></title>
|
|
|
|
<section>
|
|
<title>Description</title>
|
|
|
|
<para>This policy is used to promote safe types in arithmetic expressions
|
|
according to the rules in the C++ standard. But rather than using the
|
|
native C++ standard types supported by the compiler, it uses types whose
|
|
length in number of bits is specified by the template parameters.</para>
|
|
|
|
<para>This policy is useful for running test programs which use C++
|
|
portable integer types but which are destined to run on an architecture
|
|
which is different than the one on which the test program is being built
|
|
and run. This can happen when developing code for embedded systems.
|
|
Algorithms developed or borrowed from one architecture but destined for
|
|
another can be tested on the desktop.</para>
|
|
|
|
<para>Note that this policy is only applicable to safe types whose base
|
|
type is a type fulfilling the type requirements of <link
|
|
linkend="safe_numerics.integer">Integer</link>.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Template Parameters</title>
|
|
|
|
<informaltable>
|
|
<tgroup cols="3">
|
|
<colspec align="left" colwidth="1*"/>
|
|
|
|
<colspec align="left" colwidth="1*"/>
|
|
|
|
<colspec align="left" colwidth="6*"/>
|
|
|
|
<thead>
|
|
<row>
|
|
<entry align="left">Parameter</entry>
|
|
|
|
<entry align="left">Type</entry>
|
|
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><code>C</code></entry>
|
|
|
|
<entry>int</entry>
|
|
|
|
<entry>Number of bits in a char</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><code>S</code></entry>
|
|
|
|
<entry>int</entry>
|
|
|
|
<entry>Number of bits in a short</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><code>I</code></entry>
|
|
|
|
<entry>int</entry>
|
|
|
|
<entry>Number of bits in an integer</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><code>L</code></entry>
|
|
|
|
<entry>int</entry>
|
|
|
|
<entry>Number of bits in a long</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><code>LL</code></entry>
|
|
|
|
<entry>int</entry>
|
|
|
|
<entry>Number of bits in a long long</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Model of</title>
|
|
|
|
<para><link
|
|
linkend="safe_numerics.promotion_policy">PromotionPolicy</link></para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Example of Use</title>
|
|
|
|
<para>Consider the following problem. One is developing software which
|
|
uses a very small microprocessor and a very limited C compiler. The chip
|
|
is so small, you can't print anything from the code, log, debug or
|
|
anything else. One debugs this code by using the "burn" and "crash" method
|
|
- you burn the chip (download the code), run the code, observe the
|
|
results, make changes and try again. This is a crude method which is
|
|
usually the one used. But it can be quite time consuming.</para>
|
|
|
|
<para>Consider an alternative. Build and compile your code in testable
|
|
modules. For each module write a test which exercises all the code and
|
|
makes it work. Finally download your code into the chip and - voilà -
|
|
working product. This sounds great, but there's one problem. Our target
|
|
processor - in this case a PIC162550 from Microchip Technology is only an
|
|
8 bit CPU. The compiler we use defines INT as 8 bits. This (and a few
|
|
other problems), make our algorithm testing environment differ from our
|
|
target environment. We can address this by defining INT as a safe integer
|
|
with a range of 8 bits. By using a custom promotion policy, we can force
|
|
the evaluation of C++ expressions in the test environment to be the same
|
|
as that in the target environment. Also in our target environment, we can
|
|
trap any overflows or other errors. So we can write and test our code on
|
|
our desktop system and download the code to the target knowing that it
|
|
just has to work. This is a huge time saver and confidence builder. For an
|
|
extended example on how this is done, look at <link
|
|
linkend="safe_numerics.safety_critical_embedded_controller">Safety
|
|
Critical Embedded Controller</link> .</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Header</title>
|
|
|
|
<para><code><ulink
|
|
url="../../include/boost/safe_numerics/cpp.hpp"><code>#include
|
|
<boost/numeric/safe_numerics/cpp.hpp> </code></ulink></code></para>
|
|
</section>
|
|
</section>
|