On 31/01/2020 12:41, Luboš Luňák wrote:
I'm fine with this if this would be ok for you (the way I see it, this
o3tl::ssize() would be basically my proposed o3tl::make_signed() with a
different name).
see here:
On 30/01/2020 11:39, Stephan Bergmann wrote:
> C++20 will have ssize for container
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r2.html>
> "P1227: Signed ssize() functions, unsigned size() functions (Revision
> 2)"; and being replaced by the true std::ssize once generally
> available), and updating relevant places in the code to use that.
> (Where
On Friday 31 of January 2020, Kaganski Mike wrote:
> On 2020-01-30 17:25, Luboš Luňák wrote:
> > Not worth it. That'd be like doing error checking for every memory
> > allocation - we also bother only with those few cases where it
> > realistically can go wrong.
>
> I disagree with this approach.
ating relevant places in the code to use that.
(Where occurrences of o3tl::make_unsigned would likely be good starting
points to hunt for such places. As discussed elsewhere in this thread,
that should get rid of many, if not most of the
On 2020-01-30 17:25, Luboš Luňák wrote:
> On Thursday 30 of January 2020, Kaganski Mike wrote:
>> Can the hypothetical make_signed function return a signed integer when
>> there's a bigger integer type exist,
>
> Yes.
>
>> and a struct with overloaded
>> operator<=> when there's not, and that o
On Thursday 30 of January 2020, Kaganski Mike wrote:
> Can the hypothetical make_signed function return a signed integer when
> there's a bigger integer type exist,
Yes.
> and a struct with overloaded
> operator<=> when there's not, and that overloaded operator<=> would
> check if contained uns
I wrote, I saw lots of occurrences of (*)
> across the LO code base.
And how many occurences that do not do (*) have you seen? (I have no idea how
to reasonably search for those).
> (And, again, people writing broken code is
> something that o3tl::make_unsigned cannot and will not address.)
On 2020-01-30 15:30, Stephan Bergmann wrote:
> On 30/01/2020 12:56, Luboš Luňák wrote:
>> On Thursday 30 of January 2020, Stephan Bergmann wrote:
>>> On 29/01/2020 17:14, Luboš Luňák wrote:
Exactly my point. It's just that you seem to find it guaranteed that
people won't mess up range
a signed-vs.-unsigned warning).
that's what people will often do, and there signed is the better choice. Your
point is valid only if it assumes some ideal reality. In this reality, people
mess up, and APIs should make it harder to write possibly problematic code,
not promote it.
...which, ag
t assumes some ideal reality. In this reality, people
mess up, and APIs should make it harder to write possibly problematic code,
not promote it.
> and the newly introduced o3tl::make_unsigned merely helps
> write it in a better way (by not having to spell out U1). This is
> orthogo
k "compare a signed e1 against an unsigned
e2", (*) is the tool I at least reach for (naturally; without much of a
second thought, actually). And it has in fact been used all over the LO
code base, and the newly introduced o3tl::make_unsigned merely helps
write it in a better way (by not
On Wednesday 29 of January 2020, Stephan Bergmann wrote:
> On 29/01/2020 15:20, Luboš Luňák wrote:
> > Which is the assumption. Using o3tl::make_signed would not require such
> > an assumption, or it would be even less likely false.
>
> But a precondition-free o3tl::make_signed would need to map
On 29/01/2020 15:20, Luboš Luňák wrote:
On Wednesday 29 of January 2020, Stephan Bergmann wrote:
On 29/01/2020 11:41, Luboš Luňák wrote:
On Wednesday 29 of January 2020, Stephan Bergmann wrote:
if (o3tl::make_unsigned(e1) < e2) ...// (C)
instead of (B), avoiding an explicit cast
On Wednesday 29 of January 2020, Stephan Bergmann wrote:
> On 29/01/2020 11:41, Luboš Luňák wrote:
> > On Wednesday 29 of January 2020, Stephan Bergmann wrote:
> >> if (o3tl::make_unsigned(e1) < e2) ...// (C)
> >>
> >> instead of (B), avoiding an ex
On 29/01/2020 11:41, Luboš Luňák wrote:
On Wednesday 29 of January 2020, Stephan Bergmann wrote:
if (o3tl::make_unsigned(e1) < e2) ...// (C)
instead of (B), avoiding an explicit cast and making the intent clear.
(o3tl::make_unsigned is defined "header-only", so can be us
On Wednesday 29 of January 2020, Stephan Bergmann wrote:
>if (o3tl::make_unsigned(e1) < e2) ...// (C)
>
> instead of (B), avoiding an explicit cast and making the intent clear.
> (o3tl::make_unsigned is defined "header-only", so can be used everywhere
> L
<https://gerrit.libreoffice.org/plugins/gitiles/core/+/6417668b3e12d9659ac5dc4a2f60aa8ad3bca675%5E!/>
"Introduce o3tl::make_unsigned to cast from signed to unsigned type".
If e1 is known to be non-negative, it lets you write
if (o3tl::make_unsigned(e1) < e2) ...// (C)
instead of
17 matches
Mail list logo
