131 lines
5.9 KiB
XML
131 lines
5.9 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.pending_issues">
|
|
<title>Pending Issues</title>
|
|
|
|
<?dbhtml stop-chunking?>
|
|
|
|
<para>The library is under development. There are a number of issues still
|
|
pending.</para>
|
|
|
|
<section>
|
|
<title><code>safe_base</code> Only Works for Scalar Types</title>
|
|
|
|
<para>The following is paraphrased from an issue raised by Andrzej
|
|
Krzemieński as a <ulink
|
|
url="https://github.com/robertramey/safe_numerics/issues/44">github
|
|
issue</ulink>. It touches upon fundamental ideas behind the library and
|
|
how these ideas as the implementation of the library collided with
|
|
reality.</para>
|
|
|
|
<para><quote>In the current implementation safe<T> will only work
|
|
with T being a C++ scalar type. Therefore making a general type
|
|
requirements that say what operations are allowed is superfluous, and
|
|
confusing (because it implies that safe<> is more
|
|
generic.</quote></para>
|
|
|
|
<para>When I started out, It became clear that I wanted "safe" types to
|
|
look like "numeric" types. It also became clear pretty soon that there was
|
|
going to be significant template meta-programming in the implementation.
|
|
Normal type traits like std::is_integer are defined in the std namespace
|
|
and one is discouraged from extending it. Also I needed some compile time
|
|
"max" and "lowest" values. This lead me to base the design on
|
|
std::numeric_limits. But std::numeric limits is inherently extensible to
|
|
any "numeric" type. For example, money is a numeric type but not an
|
|
intrinsic types. So it seemed that I needed to define a "numeric" concept
|
|
which required that there be an implementation of std::numeric_limits for
|
|
any type T - such as money in this case. When I'm doubt - I tend to think
|
|
big.</para>
|
|
|
|
<para>For now though I'm not going to address it. For what it's worth, my
|
|
preference would be to do something like: <programlisting>template<typename T>
|
|
struct range {
|
|
T m_lowest;
|
|
T m_highest;
|
|
// default implementation
|
|
range(
|
|
const & T t_min,
|
|
const & T t_max
|
|
) :
|
|
m_lowest(std::numeric_limits<T>::lowest(t_min),
|
|
m_highest(std::numeric_limits<T>::max(t_max)
|
|
{}
|
|
};</programlisting></para>
|
|
|
|
<para>Then redeclare <code>safe_base</code>, etc., accordingly.</para>
|
|
|
|
<para>Also not that for C++20, template value parameters are no longer
|
|
restricted to integer primitive types buy maybe class types as well. This
|
|
means the library maybe extended to user class types without changing the
|
|
current template signatures.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Concepts are Defined but Not Enforced.</title>
|
|
|
|
<para>The following is paraphrased from an issue raised by Andrzej
|
|
Krzemieński as a <ulink
|
|
url="https://github.com/robertramey/safe_numerics/issues/46">github
|
|
issue</ulink>.</para>
|
|
|
|
<para><quote>You do not need a concept to constrain anything with it, in
|
|
your library. Or is the purpose of the Type requirements to show in detail
|
|
what it means that safe<T> is a 'drop-in replacement for
|
|
T?</quote></para>
|
|
|
|
<para>Right - currently I don't use the concept to constrain anything.
|
|
They are currently a purely "conceptual" tool to keep the design from
|
|
getting off track. This is common with other libraries such as the C++
|
|
standard library where the concepts are defined but not enforced by
|
|
compile time predicates. Hopefully in future that might change - see
|
|
below</para>
|
|
|
|
<para><quote>If you want to extend safe<T> for other integer types,
|
|
Type requirement still need to be fixed:</quote></para>
|
|
|
|
<para>Hmmmm - I'm not quite sure that this is true. One thing that IS true
|
|
is the the interface and implementation of the library will need to be
|
|
enhanced to permit "safe" to be applied to user defined types. This is
|
|
apparent now, but as my brain can only comprehend the library one piece at
|
|
a time, this design feature was lost during the implementation. In
|
|
implementing co-existence of floats with safe integers, I did refactor the
|
|
implementation in a way which I believe my eventually permit the
|
|
application to any user supplied T which implements all the required
|
|
operations of Numeric types. So as it is now this is pending. If the
|
|
library were to become widely used, there might be motivation to do this.
|
|
Time will tell. So for now I'm leaving these in the documentation and
|
|
code, even though they are not actually used.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Other Pending Issues</title>
|
|
|
|
<para><itemizedlist>
|
|
<listitem>
|
|
<para>The library is currently limited to integers. If there is
|
|
interest, it could be extended to floats and possible to user
|
|
defined types.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Although care has been taken to make the library portable, at
|
|
least some parts of the implementation - particularly
|
|
<code>checked</code> integer arithmetic - depend upon two's
|
|
complement representation of integers. Hence the library is probably
|
|
not currently portable to all other possible C++ architectures.
|
|
These days, this is unlikely to be a limitation in practice.
|
|
Starting with C++20, integer arithmetic will be guaranteed by the
|
|
C++ standard to be two's complement.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><code>std::common_type</code> is used in a variety of generic
|
|
libraries, including std::chrono. Without a specialization for
|
|
<code>safe<T></code>s one cannot use the safe wrappers e.g. as
|
|
a representation for <code>std::chrono::duration</code>.</para>
|
|
</listitem>
|
|
</itemizedlist></para>
|
|
</section>
|
|
</section>
|