+ 
|
-
+
|
Safe Numerics |
native
+ type promotion policy. Up until now, we've focused on detecting when this
+ happens and invoking an interrupt or other kind of error handler.
automatic
+ type promotion policy, we can change the rules of C++ arithmetic for safe
+ types to something like the following:
automatic
+ type promotion policy will achieve the equivalent result without
+ these problemstrap_exception
+ exception policy enforces this guarantee
"trap_exception"
- exception policy .
+ linkend="safe_numerics.exception_policies.trap_exception">trap_exception
+ exception policy.
integers as a long
- type.automatic
+ type promotion policy has rendered the result of the some of two
+ integers as a long type.trap_exception
+ exception policy"trap_exception"
- exception policy to verify at compile time that what we
- "know" to be true is in fact true.
+ linkend="safe_numerics.exception_policies.trap_exception">trap_exception
+ exception policy to verify at compile time that what we "know" to be true
+ is in fact true.
safe_t to reflect our view
- of legal values for this program. This uses automatic type promotion
- policy as well as trapping exception policy to enforce elimination
- of runtime penalties.safe_t to reflect our
+ view of legal values for this program. This uses automatic
+ type promotion policy as well as trap_exception
+ exception policy to enforce elimination of runtime penalties.safe_t so there is no need to check the input values.
+ This performs the functionality of input_safe_t to be used
+ input_safe_t to be used
when reading variables from the program console. Clearly, these can
only be checked at runtime so they use the throw_exception policy.
When variables are read from the console they are checked for legal
- values. We need no hoc code to do this, as these types are
+ values. We need no ad hoc code to do this, as these types are
guaranteed to contain legal values and will throw an exception when
this guarantee is violated. In other words, we automatically get
checking of input variables with no additional programming.input_safe_t are converted to values of type
+ safe_t . In this particular example, it can be
+ determined at compile time that construction of an instance of a
+ safe_t from an input_safe_t can never
+ fail. Hence, no try/catch block is necessary. The usage
+ of the trap_exception policy for safe_t
+ types would cause a compile time error.safe<float> and related types as well as new types
+ like safe<fixed_decimal> etc. But the current
+ version of the library only addresses integer types. Hopefully the
+ library will evolve to match the promise implied by its name.
@@ -113,22 +111,23 @@
numeric_limits for "safe"
+ types? Do you need it?safe<T> behaves like a "number" just as int
+ does. It has max, min, etc Any code which uses numeric limits to test
+ a type T should works with safe<T>.
+ safe<T> is a drop-in replacement for T
+ so it has to implement all the operations.int. Similar problems occur with other built-in integer
- types such as unsigned, long, etc. And it also applies to other operations
- such as subtraction, multiplication etc. . C/C++ often automatically and
- silently converts some integer types to others in the course of
- implementing binary operations and similar problems occur in this case as
- well. Since the problems and their solution are similar, We'll confine the
- current discussion to just this example.unsigned, long, etc. And it also
+ applies to other operations such as subtraction, multiplication etc. .
+ C/C++ often automatically and silently converts some integer types to
+ others in the course of implementing binary operations and similar
+ problems occur in this case as well. Since the problems and their solution
+ are similar, We'll confine the current discussion to just this one
+ example.
safe<int>, safe<unsigned int> etc.
- These behave exactly like the underlying types signed to unsigned
- value are not trapped at compile time - as they are legal C/C++ code.
- Instead, they are checked at runtime to trap the case where this (legal)
- operation would lead to an arithmetically incorrect result.int,
+ unsigned, etc. named safe<int>,
+ safe<unsigned int> etc. These behave exactly like the
+ underlying types signed to
+ unsigned value - are not trapped at compile time as they are
+ legal C/C++ code. Instead, they are checked at runtime to trap the case
+ where this (legal) operation would lead to an arithmetically incorrect
+ result.safe_range(Min, Max)
- and safe_literal(N). These types can be used to improve
- program correctness and performance.safe_range(Min,
+ Max) and safe_literal(N). These types can be
+ used to improve program correctness and performance.Andrzej Commented and reviewed the library as it was - originally posted on the Boost - Library Incubator. The the consequent back and forth - motivated me to invest more effort in developing documentation and - examples to justify the utility, indeed the necessity, for this - library. He also noted many errors in code, documentation, and - tests. Without his interested and effort, I do not believe the - library would have progressed beyond it's initial stages.
As always, the Boost Developer's mailing list has been the source of many useful observations from potential users and - constructive criticism from very knowledgeable developers. Boost - also supplies a widely accepted list of standards and requirements - for quality software. Finally, the Boost infrastructure for testing, - documentation is close to indispensable.
| diff --git a/doc/html/eliminate_runtime_penalty/3.html b/doc/html/eliminate_runtime_penalty/3.html index 5b68695..5f07f19 100644 --- a/doc/html/eliminate_runtime_penalty/3.html +++ b/doc/html/eliminate_runtime_penalty/3.html @@ -7,7 +7,7 @@ - + |