Re: mixed-sign arithmetic and auto
Nevin :-] Liber wrote:
In article <478114A9.20209@erdani.org>,
"Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEmail@erdani.org> wrote:
Nevin :-] Liber wrote:
auto x = static_cast<int>((i + u) / 2);
because they "know" that casts always "fix" these kinds of problems.
People tend to take the path of least resistance. In this case, I think
they'd write:
int c = (i + u) / 2;
which is shorter and does the same thing.
It means that while this compiles:
std::vector<X> v;
//...
auto middle_index_round_down = v.size() / 2;
(Background: below, by "my scheme" I denote the hypothetical use of
types intbits and longbits to encode an integral of ambiguous,
as-of-yet-undecided signedness.)
This is u / i, which (in my scheme) would return intbits. Given,
however, that 2 is a compile-time constant, the compiler could relax the
rule and type it as u / u which yields u.
the slightly different:
auto middle_index_round_up = (1 + v.size()) / 2;
would not (since it is (i + u) / 2).
Following the rule above and considering that 1 is a positive
compile-time constant, the expression would be typed as (u + u) / u
which is u again. But let's say for the argument that you use a variable:
int x = 1;
auto middle_index_round_up = (x + v.size()) / 2;
In my system hat would not issue the warning: "division has
sign-dependent semantics and was used with an expression of ambiguous sign."
Which I think is pretty neat.
Heck, even
if (!v.empty)
{
auto back_index = v.size() - 1;
// ...
}
would fail to compile.
First off, the branch is never taken because you take the address of a
member function which is never null :o).
Assuming parens after empty, the code would not fail to compile. It all
depends on what you do with back_index. That value will be typed as
intbits, and so it will have ambiguous signedness. If you later try an
operation with sign-dependent semantics (e.g. shift, promotion,
division, or modulus), a warning would ensue. Otherwise (add, subtract,
multiply), there is no warning.
In order to ensure that these types of things would compile, they would
have to go back to using std::vector<X>::size_type (or worse, they would
follow the path of least resistance and choose one of int, unsigned,
long, unsigned long or size_t). Isn't the whole point of auto so that
we don't have to use those kinds of expressions?
In my system, auto would do the right thing and also transport
information that is useful during the downstream usage of the computed
value.
Heck, if I'm using std::bitset, I have to know that the type returned by
size() is size_t, since there isn't a typedef for size_type inside of it
to use. But I digress.
Nonono, that's certainly not what I had in mind. Again: in my opinion,
it might be useful to just disallow (or warn on) the use of auto in the
most flagrant cases of unsigned type mishandling.
I just don't know how to consistently tell at compile time which ones
are flagrant.
My criterion is this: if you compute a value for which int and unsigned
are idempotent as the result type (e.g. u + i) or one for which choosing
unsigned is arguably the wrong choice (e.g. i / u), and later use that
value in ways that have sign-dependent semantics, issue a warning and
ask for the programmer to make signedness explicit. It's actually
amazing how many two's complement operations don't even care about
signedness and "just work". That's why I believe my system has low
impact on correct programs.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]