]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | <html> |
2 | <head> | |
3 | <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"> | |
4 | <title>FAQ</title> | |
5 | <link rel="stylesheet" href="../../../../../../doc/src/boostbook.css" type="text/css"> | |
6 | <meta name="generator" content="DocBook XSL Stylesheets V1.77.1"> | |
7 | <link rel="home" href="../../index.html" title="Chapter 1. Boost.Multiprecision"> | |
8 | <link rel="up" href="../map.html" title="Roadmap"> | |
9 | <link rel="prev" href="todo.html" title="TODO"> | |
10 | <link rel="next" href="ack.html" title="Acknowledgements"> | |
11 | </head> | |
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> | |
13 | <table cellpadding="2" width="100%"><tr> | |
14 | <td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../../../../boost.png"></td> | |
15 | <td align="center"><a href="../../../../../../index.html">Home</a></td> | |
16 | <td align="center"><a href="../../../../../../libs/libraries.htm">Libraries</a></td> | |
17 | <td align="center"><a href="http://www.boost.org/users/people.html">People</a></td> | |
18 | <td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td> | |
19 | <td align="center"><a href="../../../../../../more/index.htm">More</a></td> | |
20 | </tr></table> | |
21 | <hr> | |
22 | <div class="spirit-nav"> | |
23 | <a accesskey="p" href="todo.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../map.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="ack.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a> | |
24 | </div> | |
25 | <div class="section"> | |
26 | <div class="titlepage"><div><div><h3 class="title"> | |
27 | <a name="boost_multiprecision.map.faq"></a><a class="link" href="faq.html" title="FAQ">FAQ</a> | |
28 | </h3></div></div></div> | |
29 | <div class="variablelist"> | |
30 | <p class="title"><b></b></p> | |
31 | <dl class="variablelist"> | |
32 | <dt><span class="term">Why do I get compiler errors when passing a <code class="computeroutput"><span class="identifier">number</span></code> | |
33 | to a template function?</span></dt> | |
34 | <dd><p> | |
35 | Most likely you are actually passing an expression template type to | |
36 | the function and template-argument-deduction deduces the "wrong" | |
37 | type. Try casting the arguments involving expressions to the actual | |
38 | number type, or as a last resort turning off expression template support | |
39 | in the number type you are using. | |
40 | </p></dd> | |
41 | <dt><span class="term">When is expression template support a performance gain?</span></dt> | |
42 | <dd><p> | |
43 | As a general rule, expression template support adds a small runtime | |
44 | overhead creating and unpacking the expression templates, but greatly | |
45 | reduces the number of temporaries created. So it's most effective in | |
46 | improving performance when the cost of creating a temporary is high: | |
47 | for example when creating a temporary involves a memory allocation. | |
48 | It is least effective (and may even be a dis-optimisation) when temporaries | |
49 | are cheap: for example if the number type is basically a thin wrapper | |
50 | around a native arithmetic type. In addition, since the library makes | |
51 | extensive use of thin inline wrapper functions, turning on compiler | |
52 | optimization is essential to achieving high performance. | |
53 | </p></dd> | |
54 | <dt><span class="term">Do expression templates reorder operations?</span></dt> | |
55 | <dd><p> | |
56 | Yes they do, sometimes quite radically so, if this is a concern then | |
57 | they should be turned off for the number type you are using. | |
58 | </p></dd> | |
59 | <dt><span class="term">I can't construct my number type from <span class="emphasis"><em>some other type</em></span>, | |
60 | but the docs indicate that the conversion should be allowed, what's up?</span></dt> | |
61 | <dd><p> | |
62 | Some conversions are <span class="emphasis"><em>explicit</em></span>, that includes construction | |
63 | from a string, or constructing from any type that may result in loss | |
64 | of precision (for example constructing an integer type from a float). | |
65 | </p></dd> | |
66 | <dt><span class="term">Why do I get an exception thrown (or the program crash due to an | |
67 | uncaught exception) when using the bitwise operators on a checked <code class="computeroutput"><span class="identifier">cpp_int</span></code>?</span></dt> | |
68 | <dd><p> | |
69 | Bitwise operations on negative values (or indeed any signed integer | |
70 | type) are unspecified by the standard. As a result any attempt to carry | |
71 | out a bitwise operation on a negative checked-integer will result in | |
72 | a <code class="computeroutput"><span class="identifier">std</span><span class="special">::</span><span class="identifier">range_error</span></code> being thrown. | |
73 | </p></dd> | |
74 | <dt><span class="term">Why do I get compiler errors when trying to use the complement operator?</span></dt> | |
75 | <dd><p> | |
76 | Use of the complement operator on signed types is problematic as the | |
77 | result is unspecified by the standard, and is further complicated by | |
78 | the fact that most extended precision integer types use a sign-magnitude | |
79 | representation rather than the 2's complement one favored by most native | |
80 | integer types. As a result the complement operator is deliberately | |
81 | disabled for checked <code class="computeroutput"><span class="identifier">cpp_int</span></code>'s. | |
82 | Unchecked <code class="computeroutput"><span class="identifier">cpp_int</span></code>'s | |
83 | give the same valued result as a 2's complement type would, but not | |
84 | the same bit-pattern. | |
85 | </p></dd> | |
86 | <dt><span class="term">Why can't I negate an unsigned type?</span></dt> | |
87 | <dd><p> | |
88 | The unary negation operator is deliberately disabled for unsigned integer | |
89 | types as its use would almost always be a programming error. | |
90 | </p></dd> | |
91 | <dt><span class="term">Why doesn't the library use proto?</span></dt> | |
92 | <dd><p> | |
93 | A very early version of the library did use proto, but compile times | |
94 | became too slow for the library to be usable. Since the library only | |
95 | required a tiny fraction of what proto has to offer anyway, a lightweight | |
96 | expression template mechanism was used instead. Compile times are still | |
97 | too slow... | |
98 | </p></dd> | |
99 | <dt><span class="term">Why not abstract out addition/multiplication algorithms?</span></dt> | |
100 | <dd><p> | |
101 | This was deemed not to be practical: these algorithms are intimately | |
102 | tied to the actual data representation used. | |
103 | </p></dd> | |
104 | </dl> | |
105 | </div> | |
106 | </div> | |
107 | <table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> | |
108 | <td align="left"></td> | |
109 | <td align="right"><div class="copyright-footer">Copyright © 2002-2013 John Maddock and Christopher Kormanyos<p> | |
110 | Distributed under the Boost Software License, Version 1.0. (See accompanying | |
111 | file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>) | |
112 | </p> | |
113 | </div></td> | |
114 | </tr></table> | |
115 | <hr> | |
116 | <div class="spirit-nav"> | |
117 | <a accesskey="p" href="todo.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../map.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="ack.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a> | |
118 | </div> | |
119 | </body> | |
120 | </html> |