ePenguin-Software-Framework/toolchains/riscv/share/doc/gmp.html/C_002b_002b-Interface-Limit...

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- This manual describes how to install and use the GNU multiple precision
arithmetic library, version 6.1.0.

Copyright 1991, 1993-2015 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under
the terms of the GNU Free Documentation License, Version 1.3 or any later
version published by the Free Software Foundation; with no Invariant Sections,
with the Front-Cover Texts being "A GNU Manual", and with the Back-Cover
Texts being "You have freedom to copy and modify this GNU Manual, like GNU
software".  A copy of the license is included in
GNU Free Documentation License. -->
<!-- Created by GNU Texinfo 6.4, http://www.gnu.org/software/texinfo/ -->
<head>
<title>C++ Interface Limitations (GNU MP 6.1.0)</title>

<meta name="description" content="How to install and use the GNU multiple precision arithmetic library, version 6.1.0.">
<meta name="keywords" content="C++ Interface Limitations (GNU MP 6.1.0)">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link href="index.html#Top" rel="start" title="Top">
<link href="Concept-Index.html#Concept-Index" rel="index" title="Concept Index">
<link href="C_002b_002b-Class-Interface.html#C_002b_002b-Class-Interface" rel="up" title="C++ Class Interface">
<link href="Custom-Allocation.html#Custom-Allocation" rel="next" title="Custom Allocation">
<link href="C_002b_002b-Interface-Random-Numbers.html#C_002b_002b-Interface-Random-Numbers" rel="prev" title="C++ Interface Random Numbers">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.indentedblock {margin-right: 0em}
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smalllisp {margin-left: 3.2em}
kbd {font-style: oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nolinebreak {white-space: nowrap}
span.roman {font-family: initial; font-weight: normal}
span.sansserif {font-family: sans-serif; font-weight: normal}
ul.no-bullet {list-style: none}
-->
</style>


</head>

<body lang="en">
<a name="C_002b_002b-Interface-Limitations"></a>
<div class="header">
<p>
Previous: <a href="C_002b_002b-Interface-Random-Numbers.html#C_002b_002b-Interface-Random-Numbers" accesskey="p" rel="prev">C++ Interface Random Numbers</a>, Up: <a href="C_002b_002b-Class-Interface.html#C_002b_002b-Class-Interface" accesskey="u" rel="up">C++ Class Interface</a> &nbsp; [<a href="Concept-Index.html#Concept-Index" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<a name="C_002b_002b-Interface-Limitations-1"></a>
<h3 class="section">12.6 C++ Interface Limitations</h3>

<dl compact="compact">
<dt><code>mpq_class</code> and Templated Reading</dt>
<dd><p>A generic piece of template code probably won&rsquo;t know that <code>mpq_class</code>
requires a <code>canonicalize</code> call if inputs read with <code>operator&gt;&gt;</code>
might be non-canonical.  This can lead to incorrect results.
</p>
<p><code>operator&gt;&gt;</code> behaves as it does for reasons of efficiency.  A
canonicalize can be quite time consuming on large operands, and is best
avoided if it&rsquo;s not necessary.
</p>
<p>But this potential difficulty reduces the usefulness of <code>mpq_class</code>.
Perhaps a mechanism to tell <code>operator&gt;&gt;</code> what to do will be adopted in
the future, maybe a preprocessor define, a global flag, or an <code>ios</code> flag
pressed into service.  Or maybe, at the risk of inconsistency, the
<code>mpq_class</code> <code>operator&gt;&gt;</code> could canonicalize and leave <code>mpq_t</code>
<code>operator&gt;&gt;</code> not doing so, for use on those occasions when that&rsquo;s
acceptable.  Send feedback or alternate ideas to <a href="mailto:gmp-bugs@gmplib.org">gmp-bugs@gmplib.org</a>.
</p>
</dd>
<dt>Subclassing</dt>
<dd><p>Subclassing the GMP C++ classes works, but is not currently recommended.
</p>
<p>Expressions involving subclasses resolve correctly (or seem to), but in normal
C++ fashion the subclass doesn&rsquo;t inherit constructors and assignments.
There&rsquo;s many of those in the GMP classes, and a good way to reestablish them
in a subclass is not yet provided.
</p>
</dd>
<dt>Templated Expressions</dt>
<dd><p>A subtle difficulty exists when using expressions together with
application-defined template functions.  Consider the following, with <code>T</code>
intended to be some numeric type,
</p>
<div class="example">
<pre class="example">template &lt;class T&gt;
T fun (const T &amp;, const T &amp;);
</pre></div>

<p>When used with, say, plain <code>mpz_class</code> variables, it works fine: <code>T</code>
is resolved as <code>mpz_class</code>.
</p>
<div class="example">
<pre class="example">mpz_class f(1), g(2);
fun (f, g);    // Good
</pre></div>

<p>But when one of the arguments is an expression, it doesn&rsquo;t work.
</p>
<div class="example">
<pre class="example">mpz_class f(1), g(2), h(3);
fun (f, g+h);  // Bad
</pre></div>

<p>This is because <code>g+h</code> ends up being a certain expression template type
internal to <code>gmpxx.h</code>, which the C++ template resolution rules are unable
to automatically convert to <code>mpz_class</code>.  The workaround is simply to add
an explicit cast.
</p>
<div class="example">
<pre class="example">mpz_class f(1), g(2), h(3);
fun (f, mpz_class(g+h));  // Good
</pre></div>

<p>Similarly, within <code>fun</code> it may be necessary to cast an expression to type
<code>T</code> when calling a templated <code>fun2</code>.
</p>
<div class="example">
<pre class="example">template &lt;class T&gt;
void fun (T f, T g)
{
  fun2 (f, f+g);     // Bad
}

template &lt;class T&gt;
void fun (T f, T g)
{
  fun2 (f, T(f+g));  // Good
}
</pre></div>

</dd>
<dt>C++11</dt>
<dd><p>C++11 provides several new ways in which types can be inferred: <code>auto</code>,
<code>decltype</code>, etc. While they can be very convenient, they don&rsquo;t mix well
with expression templates. In this example, the addition is performed twice,
as if we had defined <code>sum</code> as a macro.
</p>
<div class="example">
<pre class="example">mpz_class z = 33;
auto sum = z + z;
mpz_class prod = sum * sum;
</pre></div>

<p>This other example may crash, though some compilers might make it look like
it is working, because the expression <code>z+z</code> goes out of scope before it
is evaluated.
</p>
<div class="example">
<pre class="example">mpz_class z = 33;
auto sum = z + z + z;
mpz_class prod = sum * 2;
</pre></div>

<p>It is thus strongly recommended to avoid <code>auto</code> anywhere a GMP C++
expression may appear.
</p></dd>
</dl>


<hr>
<div class="header">
<p>
Previous: <a href="C_002b_002b-Interface-Random-Numbers.html#C_002b_002b-Interface-Random-Numbers" accesskey="p" rel="prev">C++ Interface Random Numbers</a>, Up: <a href="C_002b_002b-Class-Interface.html#C_002b_002b-Class-Interface" accesskey="u" rel="up">C++ Class Interface</a> &nbsp; [<a href="Concept-Index.html#Concept-Index" title="Index" rel="index">Index</a>]</p>
</div>


</body>
</html>