Martin Sebor <mse...@gmail.com> writes: >> Just a stylistic thing, but since the only use of "wone" is in >> the eq_p, it'd be simpler just to use "1". Also, the maximum >> value is better calculated as "wi::max_value (prec, SIGNED)". So: >> >> /* Compute the value of SSIZE_MAX, the largest positive value that >> can be stored in ssize_t, the signed counterpart of size_t . */ >> wide_int ssize_max = wi::max_value (prec, SIGNED); >> >> return wi::eq_p (min, 1) && wi::geu_p (max, ssize_max); > > Thanks, I didn't know about the implicit conversion or the max_value > API. I'll remember to use them the next time. > > FWIW, going slightly off topic, and while I'm sure it's a matter > of getting used to the design, I can't say I find the wide_int > classes exactly intuitive. It seems that the most natural way > to write the return statement in C++ is: > > return min == 1 && max >= ssize_max; > > The first subexpression is accepted but the second one doesn't even > compile. If it did, it would treat the operands as signed which > isn't what I need here. One still has to resort to the clunky > predicate for it: > > return min == 1 && wi::geu_p (max, ssize_max);
There are two main reasons for the wi:: stuff: 1. When we were adding wide-int initially, one of the requirements was that we could operate directly on rtx and tree representations of integers, without first converting them to wide_int etc. Since trees and rtxes are pointers, it wouldn't make sense to rely on operator overloading there. 2. wide_int itself has no inherent sign. (So I disagree with "If it did, it would treat the operands as signed which isn't what I need here." The reason for not having the overload is exactly that there is no obvious choice between signed and unsigned here.) And yes, Richard has been giving me grief about the lack of a wide_int-with-sign :-) > It also doesn't help that the names of the predicates don't follow > the same convention as those that operate on trees (e.g., eq_p vs > tree_int_cst_equal). > > Unless there's some inherent limitation that makes it impossible > to use the class the way I would like it might be worth investing > some time into making it more user-friendly. I think we already provide the overloads we can (i.e. those where the sign is known or isn't relevant). Let me know if we've missed some though. Thanks, Richard
