Re: [lmi] Using unnsigned

[Greg Chicares]

On 2016-03-28 15:07, Vadim Zeitlin wrote:
> On Mon, 28 Mar 2016 14:41:32 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> [Using] signed integers in the interface as a general rule avoids [...]
> GC> problems and lets us write simpler code, faster.
> 
>  This would result in reducing everything to the lowest common denominator
> of C-like APIs.

All right, you envision a world where C-like APIs have been banished or at least
sequestered, so that we can write clear code in C++ as a high-level language.
I'm not convinced that we've yet entered that new world, but I wouldn't object
to it. I don't disagree that
  std::optional<SomeIntegerType> wxChoice::GetSelection()
would be better; it's just not available yet.

> GC> In the C family, it's customary to use "impossible" negative values to
> GC> represent errors:
> 
>  I would say "in C" instead of "C family".

There, I think, is the crux of our apparent disagreement. I do think of C++ as
a better C, but don't yet think of it as transcending C. Can it do so without
losing execution speed? I've recently been talking with someone who wants to
write a large system that must be very fast, and he's leery of C++'s possible
overhead, while I question that objection. I haven't yet studied the C++11
changes; have the designers made stuff like std::optional work at C speed?

> GC> Two options:
> GC> 
> GC> - Return unsigned when we can, and signed when we know that we'll want to
> GC> represent errors in "special" values--even though the function is 
> semantically
> GC> nonnegative. In that case, we have to look up the return values to 
> distinguish
> GC> these two possibilities.
> GC> 
> GC> - Lakos's option: always return signed for simplicity and compatibility.
> 
>  My option is the third one, as described above, i.e. return unsigned
> whenever possible and do something else (but *not* return signed int) when
> it isn't.

On this last point we still don't agree. I'd agree if we had a 'nonnegative int'
datatype, to which a negative number could not be assigned; in fact, I've tried
to do that with lmi's
  typedef tn_range<int,nonnegative_trammel<int> > tnr_nonnegative_integer;
(which of course can't be as fast as 'int' because it validates every 
assignment).

But 'unsigned int' is not such a datatype. Rather, it's a low-level C concept.
These correspondences:
  unsigned int <-> nonnegative integers
    signed int <-> integers
are arguably looser than
  double <-> real numbers
In particular, decrementing the nonnegative integer zero by one is an error,
while 0U - 1 returns some Mersenne number. I don't think of C's unsigned types
as nonnegative; I think of them as the least residue system modulo 2^word-size.
Obeying modular arithmetic is their salient characteristic; imagining 'unsigned'
to mean 'nonnegative' leads us into the 0U-1 trap. When we perform arithmetic
on wxChoice::GetSelection()'s result, we're very unlikely to stumble outside
[INT_MIN, INT_MAX], but quite likely to stumble on 0U-1; and 0-1 (signed) has
less startling behavior.