Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>After reading the standard a bit more and thinking about this, I believe I have the best answer, but I am not certain.</p> <p>First, the definition of <code>digits</code>, taken from the latest C++14 draft standard, N3797, § 18.3.2.4:</p> <blockquote> <p><code>static constexpr int digits;</code></p> <p>8 Number of <code>radix</code> digits that can be represented without change.</p> <p>9 For integer types, the number of non-sign bits in the representation.</p> <p>10 For floating point types, the number of <code>radix</code> digits in the mantissa</p> </blockquote> <p>The case of <code>bounded::integer&lt;-100, 5&gt;</code> is the same as for <code>bounded::integer&lt;0, 5&gt;</code>, which would give a value of <code>2</code>.</p> <p>For the case of <code>bounded::integer&lt;16, 19&gt;</code>, <code>digits</code> should be defined as <code>0</code>. Such a class cannot even represent a 1-bit number (since <code>0</code> and <code>1</code> aren't in the range), and according to 18.3.2.7.1:</p> <blockquote> <p>All members shall be provided for all specializations. However, many values are only required to be meaningful under certain conditions (for example, <code>epsilon()</code> is only meaningful if <code>is_integer</code> is <code>false</code>). Any value that is not "meaningful" shall be set to 0 or false.</p> </blockquote> <p>I believe that any integer-like class which does not have <code>0</code> as a possible value cannot meaningfully compute <code>digits</code> and <code>digits10</code>.</p> <p>Another possible answer is to use an information theoretic definition of digits. However, this is not consistent with the values for the built-in integers. The description explicitly leaves out sign bits, but those would still be considered a single bit of information, so I feel that rules out this interpretation. It seems that this exclusion of the sign bit also means that I have to take the smaller in magnitude of the negative end and the positive end of the range for the first number, which is why I believe that the first question is equivalent to <code>bounded::integer&lt;0, 5&gt;</code>. This is because you are only guaranteed 2 bits can be stored without loss of data. You can potentially store up to 6 bits as long as your number is negative, but in general, you only get 2.</p> <p><code>bounded::integer&lt;16, 19&gt;</code> is much trickier, but I believe the interpretation of "not meaningful" makes more sense than shifting the value over and giving the same answer as if it were <code>bounded::integer&lt;0, 3&gt;</code>, which would be <code>2</code>.</p> <p>I believe this interpretation follows from the standard, is consistent with other integer types, and is the least likely to confuse the users of such a class.</p> <p>To answer the question of the use cases of <code>digits</code>, a commenter mentioned radix sort. A base-2 radix sort might expect to use the value in <code>digits</code> to sort a number. This would be fine if you set <code>digits</code> to <code>0</code>, as that indicates an error condition for attempting to use such a radix sort, but can we do better while still being in line with built-in types?</p> <p>For unsigned integers, radix sort that depends on the value of <code>digits</code> works just fine. <code>uint8_t</code> has <code>digits == 8</code>. However, for signed integers, this wouldn't work: <code>std::numeric_limits&lt;int8_t&gt;::digits == 7</code>. You would also need to sort on that sign bit, but <code>digits</code> doesn't give you enough information to do so.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload